• 本人是某云计算小厂的一名运维工程师，在一次协助用户上云实践中，性能压力测试场景是： 用客户机去测服务端(云上)，测20W业务并发，检查服务器有没有请求中断，请求超时，请求错误等情况，错误率0.5%以下即为正常 。 最终测试结果只能到6W ，离20W 的业务要求差距很大 。

针对Linux性能问题，做以下内核参数性能调整 ，最终达到用户需求。总结出来，具有通用配置的意义，对于大并大业务场景可以默认配置

实现一台服务器的大并发，服务器支撑百万连接会出现哪些问题 ，需要说明的是：

• 服务器能够同时建立连接的数量 不是 并发量，它只是并发量一个基础。
• 服务器的并发量：一个服务器能够同时承载客户端的数量；
• 承载：服务器能够稳定的维持这些连接，能够响应请求，在200ms内返回响应就认为是ok的，其中这200ms包括数据库的操作，网络带宽，内存操作，日志等时间。

1 . 对Linux fd 的配置优化 ：

大量连接建立后 ，检查用于客户端内核日志 ，报错： Too many open files ， 检查ulimt 参数，ulimit -a |grep 'open file' 发现 open files 仅为1024

检查file-max(系统一共可以打开的最大文件数 [root@master temp]# cat /proc/sys/fs/file-max 值为378548

## ulimit和file-max, 但这两者之间的关系差别

• file-max是设置 系统所有进程一共可以打开的文件数量 。同时一些程序可以通过setrlimit调用，设置每个进程的限制。如果得到大量使用完文件句柄的错误信息，是应该增加这个值。也就是说，这项参数是系统级别的
• 即设置当前shell以及由它启动的进程的资源限制

open files 参数修改：

• 临时修改，只在当前这个会话有效：ulimit -n 1048576
• 永久修改，对所有会话有效：添加下面两行代码

[root@master temp]# vim /etc/security/limits.conf #

* soft nofile 1048576
* hard nofile 1048576

file-max参数修改：

• 临时生效： sysctl -w fs.file-max = 1048576
• 永久生效： vim /etc/sysctl.conf

2. 对Linux 端口资源的配置优化

检查内核及应用的日志 ，发现报错： Cannot assign requested address ， 从报错来看是是客户端端口资源耗尽 ， 从业务分析来看，这台虚拟机只对外开放了一个端口 ， 客户端一直访问这个端口，但是创建了有2.8W 个fd

# 执行命令可以看到socket fd 使用情况 ： cat /proc/net/sockstat

#注：
sockets: used：已使用的所有协议套接字总量
TCP: inuse：正在使用（正在侦听）的TCP套接字数量。其值≤ netstat –lnt | grep ^tcp | wc –l
TCP: orphan：无主（不属于任何进程）的TCP连接数（无用、待销毁的TCP socket数）
TCP: tw：等待关闭的TCP连接数。其值等于netstat –ant | grep TIME_WAIT | wc –l
TCP：alloc(allocated)：已分配（已建立、已申请到sk_buff）的TCP套接字数量。其值等于netstat –ant | grep ^tcp | wc –l
TCP：mem：套接字缓冲区使用量
UDP：inuse：正在使用的UDP套接字数量
FRAG：使用的IP段数量

/
proc/sys/net/ipv4/ip_local_port_range范围定义TCP和UDP通信用于选择本地端口的本地端口范围。在该文件的参数中看到两个数字：第一个数字是服务器上允许TCP和UDP通信的第一个本地端口，第二个是最后一个本地端口号。对于高使用率的系统，可以将其默认参数更改为32768-61000(first-last)或者更高

说明：
net.ipv4.ip_local_port_range的默认值为32768 61000，指的是对同一个服务器的ip+port创建28233个连接

net.ipv4.ip_local_port_range参数修改：

• 临时生效： sysctl -w net.ipv4.ip_local_port_range = 32768 63999
• 永久生效： vim /etc/sysctl.conf

3. netfilter 参数： CT 表 的配置优化

在排查日志的时候发现报错： Connection timed out 。 修改完步骤2之后，端口范围增加了3000 个，应该可以增加几百万客户端连接最少280万 ，与预期不符合

网卡接收的数据，会发送到协议栈里面，通过sk_buff将数据传到协议栈，协议栈处理完再交给应用程序。由于操作系统在使用的时候，为防止被攻击，在数据发送给协议栈之前进行一个过滤，在协议栈前面加了一个小组件：过滤器，叫做netfilter 。

从分析来看，是 netfilter 这层超时 ： netfilter不管对发送的数据，还是对接收的数据，都是可以过滤的。当连接数量达到一定数量的时候，netfilter就会不允许再对外发连接了。所以现在推测是情况1造成的，发送的SYN被netfilter拦截了 。

检查CT表情况，cat
/proc/sys/net/netfilter/nf_conntrack_max 只有13w

通过设置 通过设置netfilter允许对外最大连接数量，来解决这个问题：

nf_conntrack_max参数修改：

• 临时生效： sysctl -w net.nf_conntrack_max = 1048576
• 永久生效： vim /etc/sysctl.con

4 tcp接收缓冲区和tcp发送缓冲区参数调整

继续压力测试，跑到20W 的时候会报错： Out of memory: Kill process (C1000Kclient) score 1 or sacrifice child

这是内存不够用了，简单粗暴直接扩容内存可以让并发量跑得更高 ，实际当中我也是通过内存扩容，最终达到了压力测试要求。但是在实际分析问题中我们应该着眼问题本身 ：

tcp 连接由内核来维护，系统会为每个TCP socket创建一个发送缓冲区和一个接收缓冲区。应用程序调用write向套接字写数据时，内核从应用进程缓冲区中拷贝数据到套接字的发送缓冲区中

关于： tcp接收缓冲区和tcp发送缓冲区的逻辑，首先搞明白BDP 的概念：

BDP(带宽时延积)= RTT x 带宽

比如最大带宽是 100 MB/s，网络时延（RTT）是 10ms 时，意味着客户端到服务端的网络一共可以存放 100MB/s * 0.01s = 1MB 的字节。这个 1MB 是带宽和时延的乘积，所以它就叫「带宽时延积」（缩写为 BDP，Bandwidth Delay Product）。同时，这 1MB 也表示「飞行中」的 TCP 报文大小，它们就在网络线路、路由器等网络设备上。如果飞行报文超过了 1 MB，就会导致网络过载，容易丢包。

发送缓冲区与带宽时延积的关系：

• 如果发送缓冲区「超过」带宽时延积，超出的部分就没办法有效的网络传输，同时导致网络过载，容易丢包；
• 如果发送缓冲区「小于」带宽时延积，就不能很好的发挥出网络的传输效率。

所以，发送缓冲区的大小最好是往带宽时延积靠近

查看TCP 发送缓冲区： 发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉

查看发送缓存区：cat
/proc/sys/net/ipv4/tcp_wmem

• 第一个数值是动态范围的最小值，4096 byte = 4K；
• 第二个数值是初始默认值，87380 byte ≈ 86K；
• 第三个数值是动态范围的最大值，4194304 byte = 4096K（4M）；

查看接受缓冲区：cat
/proc/sys/net/ipv4/tcp_rmem

上面三个数字单位都是字节，它们分别表示：

第一个数值是动态范围的最小值，表示即使在内存压力下也可以保证的最小接收缓冲区大小，4096 byte = 4K；
第二个数值是初始默认值，87380 byte ≈ 86K；
第三个数值是动态范围的最大值，6291456 byte = 6144K（6M）；

在高并发场景中，为了兼顾网速与大量的并发连接，我们应当保证缓冲区的动态调整的最大值达到带宽时延积，而最小值保持默认的 4K 不变即可。而对于内存紧张的服务而言，调低默认值是提高并发的有效手段。同样，如果这是网络 IO 型服务器，那么，调大 tcp_mem 的上限可以让 TCP 连接使用更多的系统内存，这有利于提升并发能力

那么怎么判断tcp 内存是否紧张或充分呢？这是通过 tcp_mem 配置完成:

一般情况下这些值是在系统启动时根据系统内存数量计算得到的。根据当前 tcp_mem 最大内存页面数是 177120，当内存为 (177120 * 4) / 1024K ≈ 692M 时，系统将无法为新的 TCP 连接分配内存，即 TCP 连接将被拒绝