共计 3735 个字符，预计需要花费 10 分钟才能阅读完成。
LVS 系统优化的注意事项有什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
Linux 环境
CentOS 5.5
名词
LVS : Linux Virtual Server
IPVS : IP Virtual Server，IPVS 是 LVS 实现的关键。
IPVS connection hash table : IPVS 连接哈希表，用来“跟踪”进来、出去的网络包（for input and output packets lookups of IPVS)。
ip_vs_conn 结构体：定义在内核档 include/net/ip_vs.h 中。该结构体（对象）是 IPVS 的调度对象。在 32 位系统上 128 字节，64 位系统上 192 字节。
IPVS connection hash table
内核中的代码：net/netfilter/ipvs/ip_vs_conn.c
int ip_vs_conn_tab_bits;
编译时可以定，Kconfig 文件中说明该值的大小应该在 8 到 20 之间。当 ip_vs_conn_tab_bits=20 时，哈希表的的大小（条目）为 pow(2,20)，即 1048576，约 104 万，足够用了。
int ip_vs_conn_tab_size;
IPVS 哈希连接表的条目数（list_head 结构数）。
ip_vs_conn_tab_size = 1 ip_vs_conn_tab_bits;
哈希表的大小（条目数）是 2 的 ip_vs_conn_tab_bits 次方。
ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(struct list_head));
其中 IPVS 连接哈希表占用的内存大小是 ip_vs_conn_tab_size * sizeof(struct list_head)
内核 Kconfig 文件中说一个哈希条目点用 8 个字节，但是实示上，一个条目占用的内存大小是和 list_head 结构体的大小相关，（可能）在 32 位的内核里是 8 个字节，64 位的内核里是 16 个字节。当加载 ip_vs 模块的时候，使用 dmesg 可以看到具体的信息：
在 32 位系统上
IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
IPVS: ipvs loaded.
在 64 位的系统上：
IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
IPVS: ipvs loaded.
哈希冲突，是哈希算法的致命伤。“IPVS”使用“链表策略”(chaining scheme) 解决哈希冲突。当有大量的连接时，一个大的“IPVS 连接哈希表”将大大减少冲突。减少了冲突，意为着 IPVS 定位 ip_vs_conn 对象的速度更快。
下图示意了哈希表（Hash Table）这种数据结构。引用
如上图所示，首先分配一个指针数组，数组的每个元素是一个链表的头指针，每个链表称为一个槽（Slot）。哪个数据应该放入哪个槽中由哈希函数决定，在这个例子中我们简单地选取哈希函数 h(x) = x % 11，这样任意数据 x 都可以映射成 0~10 之间的一个数，就是槽的编号，将数据放入某个槽的操作就是链表的插入操作。
如果每个槽里至多只有一个数据，可以想像这种情况下 search、insert 和 delete 操作的时间复杂度都是 O(1)，但有时会有多个数据被哈希函数映射到同一个槽中，这称为碰撞（Collision），设计一个好的哈希函数可以把数据比较均匀地分布到各个槽中，尽量避免碰撞。如果能把 n 个数据比较均匀地分布到 m 个槽中，每个糟里约有 n / m 个数据，则 search、insert 和 delete 和操作的时间复杂度都是 O(n/m)，如果 n 和 m 的比是常数，则时间复杂度仍然是 O(1)。一般来说，要处理的数据越多，构造哈希表时分配的槽也应该越多，所以 n 和 m 成正比这个假设是成立的。
关联到 IPVS，ip_vs_conn_tab_size 指的就是“槽”的数量。N 指的应该是所有的调度对象 struct ip_vs_conn 的数量。
确定 ip_vs_conn_tab_bits 的 *** 值：
假如你的 LVS 上每秒有 W 个“连接”建立，平均每个“连接”将要保持 S 秒，即每个连接工作 S 秒，*** ip_vs_conn_tab_bits 值应该满足 2 的 ip_vs_conn_tab_bits 次方靠近 W*S。*** 的 ip_vs_conn_tab_bits = log(W*S,2).
还有一个容易的方法：
使用 slabtop 观察 ip_vs_conn 结构的数量（OBJS），当然，应该是在系统流量 *** 的时候取得这个值，对该值求以 2 为底 的对数，log(OBJS,2)。
获取 ip_vs_conn OBJS 的值：awk lsquo;/ip_vs_conn/{print $3} rsquo; /proc/slabinfo
这个 *** 值，以我理解，就是上面“哈希表”结构说明中提到的 M 值，而 OBJS 就是 N 值，当 M 接近 N 的时候，哈希表的复制度为 O(1)，为 *** 状态。
使我不解的是，这里为什么不设置的更大一些，仅仅是浪费一些内存而且（一个条目用去 8 或者 16 个字节）。即使取 *** 值 20, 在 64 位内核上，也才只占去 16M 的内存，在 32 位的内核上，占去 8M 内存。
IPVS 的默认值是 12，32 位机用掉 32K，64 位机用掉 64K 内存。假如不是因为小内存容易使用 CPU 缓存，那么就一定是为了节省内存，在服务器上，这样的策略，明显落后了。
问题的关键是查明 vmalloc() 函数的作用。
vmalloc() 函数的作用：
申请逻辑地址连续的内存，返回首内存地址。
看来 IPVS 连接哈希表的大小，与使用的内存（是高速缓存，还是普通内存）并无影响。
调整 ip_vs_conn_tab_bits 的方法：
新的 IPVS 代码，允许调整 ip_vs_conn_bits 的值。而老的 IPVS 代码则需要通过重新编译来调整。
在发行版里，IPVS 通常是以模块的形式编译的。
确认能否调整使用命令 modinfo -p ip_vs（查看 ip_vs 模块的参数），看有没有 conn_tab_bits 参数可用。假如可以用，那么说时可以调整，调整方法是加载时通过设置 conn_tab_bits 参数：
在 /etc/modprobe.conf 添加下面一行
options ip_vs conn_tab_bits=20
假如没有 conn_tab_bits 参数可用，则需要重新调整编译选项，重新编译。
很不幸，即使将 CentOS 内核升级到 *** 版，也不支持这个参数，只能自定义编译了（没有编译成功，很郁闷）。
另外，假如 IPVS 支持调整 ip_vs_conn_tab_bits，而又将 IPVS 集成进了内核，那么只能通过重启，向内核传递参数来调整了。在引导程序的 kernel 相关的配置行上，添加：ip_vs.conn_tab_bits=20，然后，重启。
最终建意：
增大哈希表，调到 ip_vs_conn_tab_bits 到 20。有一种说法是哈希表过大，会影响性能。但是根据我对哈希算法的理解，这种说法没有道理。
另一个有力的证据是，IPVS 的作者也是这样配置的。
Network
增加 LVS 主机的网络吞吐能力，有利于提高 LVS 的处理速度和能力。
1. 使用更快的网卡，比如使用千兆、万兆的网卡。
2. 可以进一步将两块或多块网卡绑定（多块网卡的绑定有待验证），bonding 时 mode=0（balance-rr）或者 mode=4（802.3ad，需要交换机支持聚合端口），miimon=80 或者 miimon=100（毫秒）。
TCP/IP
/etc/sysctl.conf
net.core.netdev_max_backlog = 60000
Hardware
IPVS 的运行，使用的服务器资源主要是 CPU、内存 I /O、网络 I /O；IPVS 完全运行在内存中，并且运行在内核态。
当 IPVS 的应用在 DR 模式时，即不耗 CPU，也不耗 I /O，运行非常快，所以系统负载非常的低，跟据我的经验，一般负载总是 0。所以 LVS 应用对服务器的配置要求非常低。以为 LVS 很重要，所以配置一个相当高端的服务器，实在是一种浪费。
其实我们可以做一下计算：
以 64 位系统为例，一个哈希表条目，16 个字节，一个 ip_vs_conn 结构 192 字节。以哈希表的冲突尽可能的少为场景（将 ip_vs_conn_tab_bits 设置为 *** 值 20），那么：
pow(2,20)=1048576
pow(2,20)*(16+192)/1024/1024 = 208 M
就是说，当系统当前有 100 万连接的时候，才用去内存 208 M，所以 IPVS 的主机，即使是 1G 的内存，也足以承载负载。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。
