(转)Linux kernel 性能压力下的优化实践

       做benchmark测试的过程中，总是会涉及到linux操作系统底层的设置导致无法充分利用机器的性能，在调试的过程中，不少资料没能和linux kernel版本对应上导致一些参数的设置错误。根据现有服务器的硬件条件和软件版本做相关优化，把一些实践的心得分享出来。
Kernel version ： 2.6.32-71.el6.x86_64
Cpu：Intel(R) Xeon(R) CPU    E5606 @ 2.13GHz
Memory：8G
Release notes ： v0.1 2012-03-31 句柄数，网络参数
通过ulimit改善系统性能
[longhao@longhao etc]# modprobe ip_conntrack
后续说明：
-CONNTRACK_MAX 允许的最大跟踪连接条目，是在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)
-HASHSIZE 存储跟踪连接条目列表的哈西表的大小
CONNTRACK_MAX和HASHSIZE的默认值
一般来说，CONNTRACK_MAX和HASHSIZE都会设置在“合理”使用的值上，依据可使用的RAM的大小来计算这个值。
CONNTRACK_MAX的默认值
       在i386架构上，CONNTRACK_MAX = RAMSIZE (以bytes记) / 16384 =RAMSIZE (以MegaBytes记) * 64，因此，一个32位的带512M内存的PC在默认情况下能够处理512*1024^2/16384 = 512*64 = 32768个并发的netfilter连接。
        但是真正的公式是：CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32) 这里x是指针的bit数，(例如，32或者64bit)
请注意：
－默认的CONNTRACK_MAX值不会低于128
－对于带有超过1G内存的系统，CONNTRACK_MAX的默认值会被限制在65536(但是可以手工设置成更大的值)
HASHSIZE的默认值
       通常，CONNTRACK_MAX = HASHSIZE * 8。这意味着每个链接的列表平均包含8个conntrack的条目(在优化的情况并且CONNTRACK_MAX达到的情况下)，每个链接的列表就是一个哈西表条目(一个桶)。
       在i386架构上，HASHSIZE = CONNTRACK_MAX / 8 =RAMSIZE (以bytes记) / 131072 = RAMSIZE (以MegaBytes记) * 8。举例来说，一个32位、带512M内存的PC可以存储512*1024^2/128/1024 =512*8 = 4096 个桶(链接表)
        但是真正的公式是：HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 / (x / 32)这里x是指针的bit数，(例如，32或者64bit)
请注意：
－默认HASHSIZE的值不会小于16
－对于带有超过1G内存的系统，HASHSIZE的默认值会被限制在8192(但是可以手工设置成更大的值)
--------------------------------------------------------------------------------------------------------------
转自：http://blogread.cn/it/article.php?id=5172&f=sinat