|
如上图所示,首先分配一个指针数组,数组的每个元素是一个链表的头指针,每个链表称为一个槽(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代码则需要通过重新编译来调整。
在发行版里,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的作者也是这样配置的。
|
|
|
|
|
|
|