linux 系统下的服务性能优化

Posted 2023-04-16 小海哥哥de

背景

在我们服务运行环境由物理机切换到云上后，发现服务性能有大幅下降（时延有较大的上升）。

分析

首先是服务的性能变化和上云有关。然后分析对比物理机和云的参数对比。比如外部竞争；云的宿主机系统版本；perf stat分析内存情况等。
1、外部竞争：因为云上容器是和其他容器混部，难免会受到其他容器的影响。
2、云宿主机系统版本：虽然容器的linux版本和物理机相同，但是涉及底层调度还是由宿主机系统版本决定的。
3、perf stat分析内存情况：分析物理机和云上容器的cache miss。

本次性能优化主要是cache miss导致

原因：物理机和云上容器的的LLC cache miss率 差了10%以上。
深层原因：因为我们使用的云 没有将 LLC 根据容器进行隔离。
解决方案：

(转）Linux kernel 性能压力下的优化实践(V0.1)

​​ http://www.longtask.com/blog/ ​​​
做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  句柄数  ， 网络参数

     问题1：句柄数的问题

    使用webbench在Linux下做varlish访问压力测试的时候，遇到Socket/File: Can’t open so many files的问题，原因是linux下所有的东西都是文件，包括socket接口，对于大量的网络连接，不仅仅消耗socket文件描述符，对于进程本身还打开相当多的文件，Linux的默认句柄数是1024。

解决方式：

修改/etc/security/limits.conf
     你的用户名  soft nofile 65535      ##ulimit -Sn
     你的用户名 hard nofile 65535      ##ulimit -Hn
unlimt -n 查看
参考资料：

通过ulimit改善系统性能
     问题2：网络参数

      使用ab或者webbench做压力测试，如果并发数开到1000的时候，无法完成测试。到晚上查看资料发现是linux网络参数设置。

解决方式：

[longhao@longhao etc]# vi /etc/sysctl.conf
在kernel2.6之前的添加项：
net.ipv4.netfilter.ip_conntrack_max = 655360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180
kernel2.6之后的添加项：
net.nf_conntrack_max = 655360  # net.nf_conntrack_max = 655360 也可以
net.netfilter.nf_conntrack_tcp_timeout_established = 1200

[longhao@longhao etc]# sysctl -p /etc/sysctl.conf

如果报错：error: "net.nf_conntrack_max" is an unknown key 则需要使用modprobe载入ip_conntrack模块，lsmod查看模块已载入。
[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（但是可以手工设置成更大的值）