共计 6143 个字符，预计需要花费 16 分钟才能阅读完成。
如何实现 Linux 服务器高并发调优，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
众所周知在默认参数情况下 Linux 对高并发支持并不好，主要受限于单进程最大打开文件数限制、内核 TCP 参数方面和 IO 事件分配机制等。下面就从几方面来调整使 Linux 系统能够支持高并发环境。
iptables 相关
如非必须，关掉或卸载 iptables 防火墙，并阻止 kernel 加载 iptables 模块。这些模块会影响并发性能。
单进程最大打开文件数限制
一般的发行版，限制单进程最大可以打开 1024 个文件，这是远远不能满足高并发需求的，调整过程如下：在 #号提示符下敲入：
# ulimit ndash;n 65535将 root 启动的单一进程的最大可以打开的文件数设置为 65535 个。如果系统回显类似于“Operationnotpermitted”之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了 Linux 系统对该用户打开文件数的软限制或硬限制。因此，就需要修改 Linux 系统对用户的关于打开文件数的软限制和硬限制。
第一步，修改 limits.conf 文件，并添加：
# vim /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535其中 * 号表示修改所有用户的限制；soft 或 hard 指定要修改软限制还是硬限制；65536 则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。
第二步，修改 /etc/pam.d/login 文件，在文件中添加如下行：
# vim /etc/pam.d/login sessionrequired /lib/security/pam_limits.so这是告诉 Linux 在用户完成系统登录后，应该调用 pam_limits.so 模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而 pam_limits.so 模块就会从 /etc/security/limits.conf 文件中读取配置来设置这些限制值。修改完后保存此文件。
第三步，查看 Linux 系统级的最大打开文件数限制，使用如下命令：
# cat/proc/sys/fs/file-max 32568这表明这台 Linux 系统最多允许同时打开(即包含所有用户打开文件数总和)32568 个文件，是 Linux 系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。
通常这个系统级硬限制是 Linux 系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改 /etc/sysctl.conf 文件内 fs.file-max= 131072 这是让 Linux 在启动完成后强行将系统级打开文件数硬限制设置为 131072。修改完后保存此文件。
完成上述步骤后重启系统，一般情况下就可以将 Linux 系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。
如果重启后用 ulimit- n 命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本 /etc/profile 中使用 ulimit- n 命令已经将用户可同时打开的文件数做了限制。
由于通过 ulimit- n 修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次 ulimit- n 设置的值，因此想用此命令增大这个限制值是不可能的。
所以，如果有上述问题存在，就只能去打开 /etc/profile 脚本文件，在文件中查找是否使用了 ulimit- n 限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。
通过上述步骤，就为支持高并发 TCP 连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。
内核 TCP 参数方面
Linux 系统下，TCP 连接断开后，会以 TIME_WAIT 状态保留一定的时间，然后才会释放端口。当并发请求过多的时候，就会产生大量的 TIME_WAIT 状态的连接，无法及时断开的话，会占用大量的端口资源和服务器资源。这个时候我们可以优化 TCP 的内核参数，来及时将 TIME_WAIT 状态的端口清理掉。
下面介绍的方法只对拥有大量 TIME_WAIT 状态的连接导致系统资源消耗有效，如果不是这种情况下，效果可能不明显。可以使用 netstat 命令去查 TIME_WAIT 状态的连接状态，输入下面的组合命令，查看当前 TCP 连接的状态和对应的连接数量：
# netstat-n | awk lsquo;/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]} rsquo; # 这个命令会输出类似下面的结果： LAST_ACK16 SYN_RECV348 ESTABLISHED70 FIN_WAIT1229 FIN_WAIT230 CLOSING33 TIME_WAIT18098我们只用关心 TIME_WAIT 的个数，在这里可以看到，有 18000 多个 TIME_WAIT，这样就占用了 18000 多个端口。要知道端口的数量只有 65535 个，占用一个少一个，会严重的影响到后继的新连接。这种情况下，我们就有必要调整下 Linux 的 TCP 内核参数，让系统更快的释放 TIME_WAIT 连接。
编辑配置文件:/etc/sysctl.conf，在这个文件中，加入下面的几行内容：
# vim /etc/sysctl.conf net.ipv4.tcp_syncookies= 1 net.ipv4.tcp_tw_reuse= 1 net.ipv4.tcp_tw_recycle= 1 net.ipv4.tcp_fin_timeout= 30输入下面的命令，让内核参数生效：
# sysctl-p简单的说明上面的参数的含义：
net.ipv4.tcp_syncookies= 1 #表示开启 SYNCookies。当出现 SYN 等待队列溢出时，启用 cookies 来处理，可防范少量 SYN 攻击，默认为 0，表示关闭； net.ipv4.tcp_tw_reuse= 1 #表示开启重用。允许将 TIME-WAITsockets 重新用于新的 TCP 连接，默认为 0，表示关闭； net.ipv4.tcp_tw_recycle= 1 #表示开启 TCP 连接中 TIME-WAITsockets 的快速回收，默认为 0，表示关闭； net.ipv4.tcp_fin_timeout # 修改系統默认的 TIMEOUT 时间。在经过这样的调整之后，除了会进一步提升服务器的负载能力之外，还能够防御小流量程度的 DoS、CC 和 SYN 攻击。
此外，如果你的连接数本身就很多，我们可以再优化一下 TCP 的可使用端口范围，进一步提升服务器的并发能力。依然是往上面的参数文件中，加入下面这些配置：
net.ipv4.tcp_keepalive_time= 1200 net.ipv4.ip_local_port_range= 1024 65535 net.ipv4.tcp_max_syn_backlog= 8192 net.ipv4.tcp_max_tw_buckets= 5000这几个参数，建议只在流量非常大的服务器上开启，会有显著的效果。一般的流量小的服务器上，没有必要去设置这几个参数。
net.ipv4.tcp_keepalive_time= 1200表示当 keepalive 起用的时候，TCP 发送 keepalive 消息的频度。缺省是 2 小时，改为 20 分钟。
ip_local_port_range= 1024 65535表示用于向外连接的端口范围。缺省情况下很小，改为 1024 到 65535。
net.ipv4.tcp_max_syn_backlog= 8192表示 SYN 队列的长度，默认为 1024，加大队列长度为 8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets= 5000表示系统同时保持 TIME_WAIT 的最大数量，如果超过这个数字，TIME_WAIT 将立刻被清除并打印警告信息。默认为 180000，改为 5000。此项参数可以控制 TIME_WAIT 的最大数量，只要超出了。
内核其他 TCP 参数说明
net.ipv4.tcp_max_syn_backlog= 65535 #记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有 128M 内存的系统而言，缺省值是 1024，小内存的系统则是 128。 net.core.netdev_max_backlog= 32768 # 每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。 net.core.somaxconn= 32768例如 web 应用中 listen 函数的 backlog 默认会给我们内核参数的 net.core.somaxconn 限制到 128，而 nginx 定义的 NGX_LISTEN_BACKLOG 默认为 511，所以有必要调整这个值。
net.core.wmem_default= 8388608
net.core.rmem_default= 8388608
net.core.rmem_max= 16777216 #最大 socket 读 buffer, 可参考的优化值:873200
net.core.wmem_max= 16777216 #最大 socket 写 buffer, 可参考的优化值:873200
net.ipv4.tcp_timestsmps= 0时间戳可以避免序列号的卷绕。一个 1Gbps 的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。
net.ipv4.tcp_synack_retries= 2为了打开对端的连接，内核需要发送一个 SYN 并附带一个回应前面一个 SYN 的 ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送 SYN+ACK 包的数量。
net.ipv4.tcp_syn_retries= 2在内核放弃建立连接之前发送 SYN 包的数量。
#net.ipv4.tcp_tw_len= 1 net.ipv4.tcp_tw_reuse= 1开启重用。允许将 TIME-WAITsockets 重新用于新的 TCP 连接。
net.ipv4.tcp_wmem= 8192 436600 873200TCP 写 buffer, 可参考的优化值:8192 436600 873200
net.ipv4.tcp_rmem = 32768 436600 873200TCP 读 buffer, 可参考的优化值:32768 436600 873200
net.ipv4.tcp_mem= 94500000 91500000 92700000同样有 3 个值, 意思是:
net.ipv4.tcp_mem[0]: 低于此值，TCP 没有内存压力。
net.ipv4.tcp_mem[1]: 在此值下，进入内存压力阶段。
net.ipv4.tcp_mem[2]: 高于此值，TCP 拒绝分配 socket。上述内存单位是页，而不是字节。可参考的优化值是:7864321048576 1572864
net.ipv4.tcp_max_orphans= 3276800系统中最多有多少个 TCP 套接字不被关联到任何一个用户文件句柄上。
如果超过这个数字，连接将即刻被复位并打印出警告信息。
这个限制仅仅是为了防止简单的 DoS 攻击，不能过分依靠它或者人为地减小这个值，
更应该增加这个值(如果增加了内存之后)。
net.ipv4.tcp_fin_timeout= 30如果套接字由本端要求关闭，这个参数决定了它保持在 FIN-WAIT- 2 状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是 60 秒。2.2 内核的通常值是 180 秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的 WEB 服务器，也有因为大量的死套接字而内存溢出的风险，FIN-WAIT- 2 的危险性比 FIN-WAIT- 1 要小，因为它最多只能吃掉 1.5K 内存，但是它们的生存期长些。
同时还涉及到一个 TCP 拥塞算法的问题，你可以用下面的命令查看本机提供的拥塞算法控制模块：
sysctlnet.ipv4.tcp_available_congestion_control对于几种算法的分析，详情可以参考下：TCP 拥塞控制算法的优缺点、适用环境、性能分析，比如高延时可以试用 hybla，中等延时可以试用 htcp 算法等。
如果想设置 TCP 拥塞算法为 hybla
net.ipv4.tcp_congestion_control=hybla额外的，对于内核版高于于 3.7.1 的，我们可以开启 tcp_fastopen：
net.ipv4.tcp_fastopen= 3IO 事件分配机制
在 Linux 启用高并发 TCP 连接，必须确认应用程序是否使用了合适的网络 I / O 技术和 I / O 事件分派机制。可用的 I / O 技术有同步 I /O，非阻塞式同步 I /O，以及异步 I /O。在高 TCP 并发的情形下，如果使用同步 I /O，这会严重阻塞程序的运转，除非为每个 TCP 连接的 I / O 创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高 TCP 并发的情形下使用同步 I / O 是不可取的，这时可以考虑使用非阻塞式同步 I / O 或异步 I /O。非阻塞式同步 I / O 的技术包括使用 select()，poll()，epoll 等机制。异步 I / O 的技术就是使用 AIO。
从 I / O 事件分派机制来看，使用 select()是不合适的，因为它所支持的并发连接数有限 (通常在 1024 个以内)。如果考虑性能，poll() 也是不合适的，尽管它可以支持的较高的 TCP 并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在 I / O 事件分派不均，导致部分 TCP 连接上的 I / O 出现“饥饿”现象。而如果使用 epoll 或 AIO，则没有上述问题(早期 Linux 内核的 AIO 技术实现是通过在内核中为每个 I / O 请求创建一个线程来实现的，这种实现机制在高并发 TCP 连接的情形下使用其实也有严重的性能问题。但在最新的 Linux 内核中，AIO 的实现已经得到改进)。
综上所述，在开发支持高并发 TCP 连接的 Linux 应用程序时，应尽量使用 epoll 或 AIO 技术来实现并发的 TCP 连接上的 I / O 控制，这将为提升程序对高并发 TCP 连接的支持提供有效的 I / O 保证。
经过这样的优化配置之后，服务器的 TCP 并发处理能力会显著提高。以上配置仅供参考，用于生产环境请根据自己的实际情况调整观察再调整。
关于如何实现 Linux 服务器高并发调优问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
