Linux之性能优化

优化内核相关参数

配置文件/etc/sysctl.conf
配置方法直接将参数添加进文件每条一行

sysctl -a 可以查看默认配置
sysctl -p 执行并检测是否有错误

1. 网络相关

net.core.somaxconn=65535
一个端口最大监听TCP连接队列的长度

net.core.netdev_max_backlog=65535
数据包速率比内核处理快时,送到队列的数据包上限

net.ipv4.tcp_max_syn_backlog=65535
TCP syn 队列的最大长度, 第一次握手的连接参数过大可能也会遭受syn flood攻击

net.ipv4.tcp_fin_timeout=10
fin超时时间,表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间

net.ipv4.tcp_tw_reuse=1
是否允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0 关闭

net.ipv4.tcp_tw_recycle=1
是否开启TCP连接中TIME-WAIT sockets的快速回收，默认为0 关闭

关于网络参数调优模板,主机配置为8G和16G内存【按需调整】

注意：
参数值并不是设置的越大越好，有的需要考虑服务器的硬件配置，参数对服务器上其它服务的影响等。

2. 本地端口号

有时候我们修改了文件句柄限制数后，错误日志又会提示 "Can’t assignrequested address"。
这是因为TCP 建立连接，在创建 Socket 句柄时，需要占用一个本地端口号（与 TCP 协议端口号不一样），相当于一个进程，便于与其它进程进行交互。
而Linux内核的TCP/IP 协议实现模块对本地端口号的范围进行了限制。当端口号用尽，就会出现这种错误了。

我们可以修改本地端口号的范围。

#查看IP协议本地端口号限制
cat /proc/sys/net/ipv4/ip_local_port_range

#一般系统默认为以下值
32768    61000

#修改本地端口号
vim /etc/sysctl.conf

#修改参数
net.ipv4.ip_local_port_range = 1024 65000

#保存修改后，需要执行sysctl命令让修改生效
sysctl -p

注意：
1、net.ipv4.ip_local_port_range的最小值为1024，1024以下的端口已经规划为TCP协议占用，如果想将 TCP 协议端口设置为8080等大端口号，可以将这里的最小值调大。
2、如果存在应用服务端口号大于1024的，应该将 net.ipv4.ip_local_port_range 的起始值修改为大于应用服务端口号，否则服务会报错。

kernel.shmmax=4294967295
该参数定义了共享内存段的最大尺寸（以字节为单位）。

其值应>=sag_max_size初始化参数的大小,否则SAG由多个内存段构成,效率降低,
还要不小于物理内存的一半,默认情况下在32位x86系统中,Oracle SGA最大不能超过1.7GB.

kernel.shmmni=4096
这个内核参数用于设置系统范围内共享内存段的最大数量。该参数的默认值是 4096.

kernel.shmall = 2097152
该参数表示系统任意时刻可以分配的所有共享内存段的总和的最大值(以页为单位).

其值应不小于shmmax/page_size.缺省值就是2097152，如果服务器上运行的所有实例的
SGA总和不超过8GB(通常系统可分配的共享内存的和最大值为8GB),通常不需要修改.

vm.swappiness=0

内存分配策略,设置为0是告诉系统除非虚拟内存完全满了 否则不要使用交换区

风险:

降低操作系统性能
在系统资源不足下,容易被OOM kill掉

提高资源限制上限

配置文件位于 /etc/security/limit.conf

* soft nofile 65535
* hard nofile 65535

• " * "对所有用户有效
• soft 当前系统生效的设置
• hard 系统所能设定的最大值
• nofile 打开文件的最大数目
• 65535 限制的数量
• 需要重启系统生效

一次nginx在早高峰时段大量用户同时请求验证出现连接缓慢问题，问题是由于资源限制问题导致

• 日志信息

2024/04/25 08:31:23 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:24 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:24 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:25 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:25 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:26 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:26 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:27 [crit] 37451#0: accept4() failed (24: Too many open files)
2024/04/25 08:31:27 [crit] 37451#0: accept4() failed (24: Too many open files)

• 报错原因
  通过ulimit -a命令查询，发现主机最初设置系统文件最大打开数（open files ）过于保守，致使早高峰时段大量用户同时请求验证出现连接缓慢问题。

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127886
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127886
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

进一步查看nginx进程的limit限制，发现nginx主进程软限制是1024，硬限制是4096。

• 解决方式
  修改配置文件/etc/security/limits.conf，增加配置以下配置并重启Nginx主进程：

root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535

Nginx配置文件增加配置：

worker_rlimit_nofile 65535;

• 验证
  nginx进程最大文件打开数已设置成功
  

磁盘调度策略

参数路径:/sys/block/devname/queue/scheduler

简介:

• noop电梯式调度策略
  实现了一个FIFO队列 倾向饿死读而利于写 对闪存设备 RAM和嵌入式系统是最好的选择

• deadline 截止时间调度策略
  确保了在一个截止时间内服务请求 这个截止时间是可调整的 而默认读期限短于写期限
  对于数据库类应用是最好的选择

• anticipatory 预料IO调度策略
  本质上和deadline一样 但在最后一次读操作后 要等待6ms 才能继续进行对其他IO请求进行调度 将一些小写入流合并成一个大写入流 用写入延迟换取最大的写入吞吐量 适合写入较多的环境 比如文件服务器 对数据库环境表现很差

• cfq 绝对公平算法

内核参数存储路径

转载
https://mp.weixin.qq.com/s/ipevyg1WzQJB0o_3cMauew