我才知道的淘宝内核对LVS的性能优化

2019独角兽企业重金招聘Python工程师标准>>>

 简单公布一下测试结果：在一台普通的4核服务器上，使用LVS的DR模式，后端7台RealServer。在CentOS原生内核上，每秒最高转发约6万个HTTP请求，而使用淘宝内核后可高达约14万次请求每秒（瓶颈在测试机，无法模拟更大压力）。而在这台服务器上直接测试Nginx状态页，最高每秒处理约4万次请求。
    当下，我们非常迫切需要解决的就是LVS的性能问题。在得到验证的同时，更希望把问题弄清楚。淘宝内核到底对LVS做了什么，让它的性能得到如此提升？

    在淘宝内核目录下，在各种Patch“patches.driver”、“patches.taobao”、等，数量多到让人望而生畏……

    好吧，我还是想把问题弄清楚！

    所有Patch中，与LVS相关的只有 patches.taobao/ip_vs_conn_locking_granularity.patch 文件。内容也很简单，仅将 CT_LOCKARRAY_BITS 由4改为8。而且是文嵩大神亲自打上的：

    这个大小从上下文来看，似乎是一个并发锁的数量。 并发锁多了， 可以同时进行的转发连接就多了， CPU不用等待任务完成。批注中注明了是针对16核做的调整，虽然我的测试里才有4核 ^_^||

    幸亏淘宝内核可以自由的选择开启或关闭指定的Patch（执行打包之前修改series.conf注释掉不想要的Patch），于是我关闭了LVS的Patch。再测试，又一次喜剧发生了：即使不打ip_vs_conn_locking_granularity.patch，淘宝内核的LVS转发功能依然很强劲！

    然后，我关闭了淘宝所有Patch。喜剧仍然存在：凡是自行定制的内核，LVS性能很平庸；凡是使用淘宝内核，无论怎样调整Patch，性能都会很强劲。那一刻，我的心你懂的……

   咨询了一下佳明和炳天，
我感觉我找到原因了：淘宝对内核的配置也进行了大量的优化。针对LVS的优化就是将CONFIG_IP_VS_TAB_BITS由12调整到
20“sed -i 's/CONFIG_IP_VS_TAB_BITS=12/CONFIG_IP_VS_TAB_BITS=20
/g' SOURCES/config-generic”：

yum -y install kernel-devel rpm-build redhat-rpm-config asciidoc hmaccalc binutils-devel elfutils-libelf-devel newt-devel zlib-devel xmlto python-devel perl-ExtUtils-Embed fedora-packager @development-tools
rpmdev-setuptree
rpm -ivh kernel-2.6.32-279.19.1.el6.src.rpm    
cd ~/rpmbuild/
cp patches.taobao/ip_vs_conn_locking_granularity.patch SOURCES/   
sed -i 's/CONFIG_IP_VS_TAB_BITS=12/CONFIG_IP_VS_TAB_BITS=20/g' SOURCES/config-generic
rpmbuild -bb --with baseonly --with firmware --without debuginfo SPECS/kernel.spec   
# waiting for lock on `./random_seed'...   
rngd -r /dev/urandom

    OK，果然很强大，应用到生产环境后效果也很满意。真心感谢淘宝、感谢开源！于是我也对此打了一个Patch，并上传了编译结果：kernel-firmware，kernel。

    怎样验证我们的优化是否生效呢，查看`ipvsadm -Ln`的size即可：

    当然，淘宝对LVS的优化不仅文章介绍的2处了。还有针对网卡和系统参数的调整比如：

# 关闭网卡LRO和GRO   
ethtool -K em1 gro off   
ethtool -K em1 lro off   
# 禁用ARP，增大backlog并发数   
net.ipv4.conf.all.arp_ignore = 1   
net.ipv4.conf.all.arp_announce = 2    
net.core.netdev_max_backlog = 500000   
# 调整内核的时钟机制   
kernel nohz=off   
# 手动调整网卡中断分布，等……

转载于:https://my.oschina.net/u/3346994/blog/907035