大流量并发LVS负载

今天药忘吃喽~ 2022-02-28 19:05 215阅读 0赞

编者按：本文对大流量、高负载LVS系统优化提供了参考意见，从IPVS、网卡、TCP/IP配置、硬件资源配置等方面进行了阐述。文章重点关注了IPVS connection hash table的参数计算过程。

### **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）这种数据结构。引用

![0_1329914251Beel.gif][]

如上图所示，首先分配一个指针数组，数组的每个元素是一个链表的头指针，每个链表称为一个槽（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 ‘/ip\_vs\_conn/\{print $3\}’  /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代码则需要通过重新编译来调整。