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

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


应用场景

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

 

服务器配置

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

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

[plain] view plain copy
  1. * soft nofile 1048576  
  2. * hard nofile 1048576  

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

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

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

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

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

 

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

[plain] view plain copy
  1. cat /proc/sys/net/ipv4/ip_local_port_range   
  2. 32768 61000  


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

[plain] view plain copy
  1. net.ipv4.ip_local_port_range= 1024 65535  

保存,使之生效

[plain] view plain copy
  1. 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
  1. net.ipv4.tcp_mem= 786432 2097152 3145728  
  2. net.ipv4.tcp_rmem= 4096 4096 16777216  
  3. net.ipv4.tcp_wmem= 4096 4096 16777216  
  4. 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
  1. fs.file-max= 10485760  
  2. net.ipv4.ip_local_port_range= 1024 65535  
  3. net.ipv4.tcp_mem= 786432 2097152 3145728  
  4. net.ipv4.tcp_rmem= 4096 4096 16777216  
  5. net.ipv4.tcp_wmem= 4096 4096 16777216  
  6. net.ipv4.tcp_max_orphans= 131072   

 

/etc/security/limits.conf 修改:

[plain] view plain copy
  1. * soft nofile 1048576  
  2. * hardnofile 1048576  
  3.    

线上测试

使用ucloud云主机进行测试,服务器配置:



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







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

 

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

[plain] view plain copy
  1. 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
  1. 10m/10m-cli<S> 100 300 10000000 500 10 600 64 301  


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





消耗资源:



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

   

客户端报错:

[plain] view plain copy
  1. 0m-cli:handy/logging.cc:164: void handy::Logger::logv(int, const char*, int, constchar*, const char*, ...): Assertion `0' failed.  
  2. 2017/05/03-15:54:58.4048281a46 FATAL handy/poller.cc:35 epoll_ctl add failed 28 No space left on device  
  3. 2017/05/03-15:54:58.4048121a40 FATAL handy/poller.cc:35 epoll_ctl add failed 28 No space left on device  
  4. 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个连接,提高连接创建的成功率。

阅读更多
个人分类: J2EE
上一篇模拟百万级TCP并发
下一篇SSM框架使用POI技术导出Excel表
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭