单机服务器支持千万级并发长连接的压力测试

http://blog.csdn.net/lijinqi1987/article/details/74545851

应用场景

聊天室或即时消息推送系统等，因为很多消息需要到产生时才推送给客户端，所以当没有消息产生时，就需要hold住客户端的连接，这样，当有大量的客户端时，要hold住大量的长连接。

 

服务器配置

此处我们按照10M并发连接为目标进行配置。

一般服务器默认限制1024个文件句柄，也就是最多支持1024个并发长连接，在root用户下编辑/etc/security/limits.conf文件，修改：

[plain] view
plain copy

* soft nofile 1048576  

* hard nofile 1048576  

·soft是一个警告值，而hard则是一个真正意义的阈值，超过就会报错。

·soft 指的是当前系统生效的设置值。hard 表明系统中所能设定的最大值

·nofile – 单进程打开文件的最大数目

·星号表示针对所有用户，若仅针对某个用户登录ID，请替换星号

这样理论上10个进程可以达到10m个并发长连接，但是在测试时会发现，并发数最多只能到达28200左右，此时，需要修改默认的本地端口范围。

 

linux系统端口范围为0-65536，系统提供了默认的端口范围：

[plain] view
plain copy

cat /proc/sys/net/ipv4/ip_local_port_range   

32768 61000  

故当前端口使用范围为61000-32768约为28200个，将端口范围扩大，修改/etc/sysctl.conf，增加一行：

[plain] view
plain copy

net.ipv4.ip_local_port_range= 1024 65535  

保存，使之生效

[plain] view
plain copy

sysctl –p  

接着在测试端程序发出的连接数量大于某个值（大概为40万时）是，通过dmesg命令查看会得到大量警告信息：[warn]socket: Too manyopenfiles in system

此时需要修改file-max，表示系统所有进程最多允许同时打开所有的文件句柄数，系统级硬限制。添加fs.file-max = 1048576到/etc/sysctl.conf中，sysctl -p保存并使之生效。

 

在服务端连接达到一定数量时，通过查看dmesg命令查看，发现大量TCP: toomany of orphaned sockets错误，此时需要调整tcp socket参数，添加：

[plain] view
plain copy

net.ipv4.tcp_mem= 786432 2097152 3145728  

net.ipv4.tcp_rmem= 4096 4096 16777216  

net.ipv4.tcp_wmem= 4096 4096 16777216  

net.ipv4.tcp_max_orphans= 131072   

net.ipv4.tcp_rmem用来配置读缓冲的大小，三个值，第一个是这个读缓冲的最小值，第三个是最大值，中间的是默认值。我们可以在程序中修改读缓冲的大小，但是不能超过最小与最大。为了使每个socket所使用的内存数最小，我这里设置默认值为4096。

net.ipv4.tcp_wmem用来配置写缓冲的大小。

读缓冲与写缓冲的大小，直接影响到socket在内核中内存的占用。

而net.ipv4.tcp_mem则是配置tcp的内存大小，其单位是页，1页等于4096字节。三个值分别为low, pressure, high

·low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。

·pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。

·high：允许所有tcp sockets用于排队缓冲数据报的页面量，当内存占用超过此值，系统拒绝分配socket，后台日志输出“TCP: too many of orphaned sockets”。

 

一般情况下这些值是在系统启动时根据系统内存数量计算得到的。 根据当前tcp_mem最大内存页面数是1864896，当内存为(1864896*4)/1024K=7284.75M时，系统将无法为新的socket连接分配内存，即TCP连接将被拒绝。实际测试环境中，据观察大概在99万个连接左右的时候(零头不算)，进程被杀死，触发outof socket memory错误（dmesg命令查看获得）。每一个连接大致占用7.5K内存（下面给出计算方式），大致可算的此时内存占用情况（990000 * 7.5/ 1024K =
7251M)。这样和tcp_mem最大页面值数量比较吻合，因此此值也需要修改。

另外net.ipv4.tcp_max_orphans这个值也要设置一下，这个值表示系统所能处理不属于任何进程的 socket数量，当我们需要快速建立大量连接时，就需要关注下这个值了。当不属于任何进程的socket的数量大于这个值时，dmesg就会看 到”too many of orphaned sockets”。

 

综上，服务端需要配置的内容做个汇总：

/etc/sysctl.conf 添加：

[plain] view
plain copy

fs.file-max= 10485760  

net.ipv4.ip_local_port_range= 1024 65535  

net.ipv4.tcp_mem= 786432 2097152 3145728  

net.ipv4.tcp_rmem= 4096 4096 16777216  

net.ipv4.tcp_wmem= 4096 4096 16777216  

net.ipv4.tcp_max_orphans= 131072   

 

/etc/security/limits.conf 修改：

[plain] view
plain copy

* soft nofile 1048576  

* hardnofile 1048576  

   

线上测试

使用ucloud云主机进行测试，服务器配置：



启动压测前系统资源情况：







使用https://github.com/yedf/handy 库自带的测试程序，进行单机并发长连接测试，该库在linux系统上使用epoll，在MacOSX上使用kqueue。

 

选取一台主机S作为服务器，运行服务器

[plain] view
plain copy

10m/10m-svr100 300 10 301 #启动10个子进程，每个进程分别监听100-300的端口。  

选取另一台主机C作为客户端，运行客户端，（S为服务器的内网ip）

#启动10个客户端子进程，连接到S的100-300端口，发起10m个连接，在500秒内创建所有的连接，每600秒发送一个心跳，心跳数据为64字节，多进程的管理端口为301。

[plain] view
plain copy

10m/10m-cli<S> 100 300 10000000 500 10 600 64 301  

在服务器端使用watch ss –s  发现tcp连接数持续上升，最终稳定在4m左右





消耗资源：



系统占用了20G左右的内存，但cpu占用极少

   

客户端报错：

[plain] view
plain copy

0m-cli:handy/logging.cc:164: void handy::Logger::logv(int, const char*, int, constchar*, const char*, ...): Assertion `0' failed.  

2017/05/03-15:54:58.4048281a46 FATAL handy/poller.cc:35 epoll_ctl add failed 28 No space left on device  

2017/05/03-15:54:58.4048121a40 FATAL handy/poller.cc:35 epoll_ctl add failed 28 No space left on device  

2017/05/03-15:54:58.4048251a45 FATAL handy/poller.cc:35 epoll_ctl add failed 28 No space left on device  

此错误一般是磁盘满导致，但是在这里是客户端在进行epoll_ctl时，内存已满导致注册epoll事件失败，所以客户端此时停止继续创建连接，可见此时的瓶颈出现在压测的客户端，如果客户端内存够用，理论上服务端10m个并发长连接应该可以实现。

 

说明:

单进程最大文件数量限制：ulimit -n 最多能把这个数字修改到1048575，因此单个进程最多能够打开百万个文件，千万并发连接需要千万个文件描述符，于是我们使用多进程来做到千万文件的支持。

 

多进程之间的负载均衡：nginx使用多进程来增加自己的吞吐量，原先采用共享锁的方式来平衡负载，对核数较多的服务器，较多的进程并没有达到性能的线性提升。最新的linux内核引入了SO_REUSEPORT选项，该选项可以自动平衡监听同一端口的多进程，是内核级的解决方案。handy采用该方案，优于nginx的旧有方式（最新的nginx也支持SO_REUSEPORT）。

 

测试中客户端本地端口不够：让服务器监听了200个端口，这样客户端连接服务器的每个端口只有50k个连接，然后加大默认的本地端口范围就可以满足要求（见前面的服务器系统参数）。

 

测试中如果一次性创建千万个连接，则绝大部分的连接创建都会失败，因此让客户端每100ms创建2000个连接，提高连接创建的成功率。