物联网架构实例—解决Linux(Ubuntu)服务器最大TCP连接数限制

1.前言：
在对物联网网关进行压测的时候，发现在腾讯云部署网关程序，设备接入数量只能达到4000多个长连接，之后就再也无法接入终端了。

之前在阿里云部署的时候明明可以到达2万左右，而且腾讯云的这个服务器比阿里云的硬件配置还要高上不少，不至于那么差，随后查阅大量资料终于完美解决。

2.解决步骤：
2.1.修改/etc/security/limits.conf文件
执行脚本：

vim /etc/security/limits.conf
在文件中添加如下行(*指代系统用户名)，修改Linux系统对用户的关于打开文件数的软限制和硬限制：

*soft nofile 65535
*hard nofile 65535
2.2.修改/etc/pam.d/login文件
执行脚本：

vim /etc/pam.d/login
在文件中添加如下行：

session required /lib/security/pam_limits.so
如果是64bit系统的话，应该为

session required /lib64/security/pam_limits.so
2.3.修改/etc/sysctl.conf文件
执行脚本

vim /etc/sysctl.conf
在文件中添加如下行（修改网络内核对TCP连接的有关限制）：

net.ipv4.tcp_mem = 786432 2097152 3145728
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_max_tw_buckets=55000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
fs.file-max=655350
2.4.执行行如下命令（使上述设置生效）
/sbin/sysctl -p /etc/sysctl.conf
/sbin/sysctl -w net.ipv4.route.flush=1
2.5.执行如下命令（linux系统优化完网络必须调高系统允许打开的文件数才能支持大的并发）
echo ulimit -HSn 65536 >> /etc/rc.local
echo ulimit -HSn 65536 >>/root/.bash_profile
ulimit -HSn 65536
2.6.重启电脑
执行命令：

reboot
原本以为上述操作执行万后，连接数就可以上去了，最后发现竟然没有效果，是因为有一处程序的限制没有打开，下面就着重说一下这里，这个也是让我纠结了2天的才解决的。

2.7.修改程序限制
打开我的程序日志，发现终端连接数只要一到4000多以上就会频发出现一个错误，java.io.IOException:Too many open files，所以明显程序的限制没有生效。

 

 

既然找到了问题，就朝着这个方向查询资料，为啥Linux的配置都已经生效，味道部署的程序不生效？

找到程序对应的PID，因为我这边是Java程序，所以使用命令：

ps -ef|grep -i java

 

找到自己受限制的程序PID然后使用cat 命令查看程序的限制，执行命令：

cat /proc/1484/limits #1484是我那个网关程序的PID

 

查了大量资料后才知道：在Centos7 与 ubuntu 系统中，/etc/security/limits.conf文件的配置作用域缩小了。/etc/security/limits.conf的配置，只适用于通过PAM认证登录用户的资源限制，它对systemd的service的资源限制不生效。

如果是登录用户，通过/etc/security/limits.conf与/etc/security/limits.d下的文件设置即可。

但是对于systemd service的资源设置（我们部署的运行程序则属于此项），则需修改全局配置：及下面两个配置文件：

配置文件1：

vim /etc/systemd/system.conf

 

配置文件2：

vim /etc/systemd/user.conf

 

在这两个配置内增加下面两行：

DefaultLimitNOFILE=65535
DefaultLimitNPROC=65535
其中：system.conf是系统实例使用的；user.conf是用户实例使用的。

修改之后重启系统，可以使用脚本（reboot），但是有的Shell工具貌似对此脚本有限制，我这边使用的是XShell进行操作的，是可以正常执行reboot脚本进行服务器的重启，然后执行下面的命令查看修改后的限制是否正常。

cat /proc/1513/limits #1513为程序的PID

 

最终搞明白了Linux服务器对连接数的限制原理，对于Linux服务器而已所有的TCP链路都是打开文件句柄 ，所以提升TCP连接数就是对开放对文件句柄的限制。

 

 

3.顺利进行了压力测试
通过上述操作，目前我使用单台4核8G服务器，连接数量接入到25000个，单机并发处理能力（含存储到数据库）在5500个包/秒。

 

————————————————
版权声明：本文为CSDN博主「大鱼>」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_17486399/article/details/128347986