NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64

简介: http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=190176&id=4234854 一 前言   当管理大量连接时,特别是只有少量活跃连接,NGINX有比较好的CPU和RAM利用率,如今是多终端保持在线的时代,更能让NGINX发挥这个优点。

 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=190176&id=4234854

一 前言
 
当管理大量连接时,特别是只有少量活跃连接,NGINX有比较好的CPU和RAM利用率,如今是多终端保持在线的时代,更能让NGINX发挥这个优点。本文做一个简单测试,NGINX在一个普通PC虚拟机上维护100k的HTTP长连接,然后查看NGINX和系统的资源利用率。
 
二 测试环境
 
1.服务端
 
硬件:双核2.3GHz,2GB内存
软件:CentOS 6.5, kernel 2.6.32,  gcc 4.4.7, nginx 1.4.7
IP:10.211.55.8
 
内核参数调整:
$ /sbin/sysctl -w net.netfilter.nf_conntrack_max=102400 # 提升系统整体连接数
$ /sbin/sysctl net.netfilter.nf_conntrack_max #验证是否生效
 
NGINX从源码编译时带--with-http_stub_status_module,只列出与默认设置不同的部分:
worker_rlimit_nofile 102400;
events {
    worker_connections  102400;
}
http {
       # 设一个比较大得超时,客户端能以平缓的方式发送HEAD请求来维持KeepAlive
       keepalive_timeout  3600;
 
        #监控连接数,本机访问
        location /nginx_status {
            stub_status on;
            access_log   off;
            allow 127.0.0.1;
            deny all;
        }
}
 
 
2. 客户端1
 
硬件:双核2.3GHz,2GB内存
软件:CentOS 6.5, kernel 2.6.32, gcc 4.4.7, Python 3.3.5
IP:10.211.55.9
 
内核参数调整:
$ /sbin/sysctl -w net.ipv4.ip_local_port_range="1024 61024” #实际只使用50000个端口
$ /sbin/sysctl net.ipv4.ip_local_port_range #验证是否生效
$ vi /etc/security/limits.conf #提升当前用户的最大打开文件数nofile(hard >= soft > 50000)
$ ulimit -n #验证是否生效,可能需重启shell
 
Python 3.3.5从源码编译,如下配置:
$ pyvenv ~/pyvenv #创建虚拟环境,便于测试
$ . ~/pyvenv/bin/activate #激活虚拟环境
(pyvenv) $ python get-pip.py #从pip官网下载get-pip.py
(pyvenv) $ pip install asyncio #安装异步IO模块
 
因为Apache ab只能批量请求,不能维持连接,所以自己写了一个HTTP长连接测试工具asyncli.py,详细实现见 http://blog.chinaunix.net/uid-190176-id-4223282.html
基本用法:
(pyvenv) $ python  asyncli.py --help
usage:  asyncli.py [-h] [-c CONNECTIONS] [-k KEEPALIVE] url
 
asyncli
 
positional arguments:
  url                   page address
 
optional arguments:
  -h, --help            show this help message and exit
  -c CONNECTIONS, --connections CONNECTIONS
                        number of connections simultaneously
  -k KEEPALIVE, --keepalive KEEPALIVE
                        HTTP keepalive timeout
 
工作机制:
每隔10毫秒连续创建10个连接(每秒约1000个连接),直到总连接数达到CONNECTIONS,每个连接都会睡眠[1, KEEPALIVE / 2]的一个随机数(单位为秒),然后向服务端url发送一个HEAD请求来维持HTTP KeepAlive,然后重复上一个睡眠步骤。。。
 
3. 客户端2
 
与客户端1完全一致,除了IP为10.211.55.10
 
三 运行与输出
 
1. 服务端系统空闲
# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 1723336  11624  76124    0    0    62     1   26   28  0  0 100  0  0
 
2. 服务端启动NGINX,无外部WEB请求
# nginx
# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 1681552  11868  76840    0    0    50     1   24   25  0  0 100  0  0 
 
3. 客户端1和2先后启动,每个客户端发起50000个长连接,并维持直到服务端关闭或超时
(pyvenv) $ python  asyncli.py -c 50000 -k 3600  http://10.211.55.8/ &
 
4. 约2小时后。。。查看服务端
# curl  http://127.0.0.1/nginx_status
Active connections: 100001
server accepts handled requests
 165539 165539 1095055
Reading: 0 Writing: 1 Waiting: 100000
 
# ps -p 1899 -o pid,%cpu,%mem,rss,comm
  PID %CPU %MEM   RSS COMMAND
 1899  2.0  4.9 94600 nginx
 
# vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 654248  62920 158924    0    0     6     6  361  108  0  1 98  0  0    
 0  0      0 654232  62920 158952    0    0     0    85  804  218  0  1 98  0  0    
 0  0      0 654108  62928 158976    0    0     0     9  813  214  0  1 98  0  0    
 0  0      0 654108  62928 159004    0    0     0     0  803  220  0  1 99  0  0    
^C
 
# free
             total       used       free     shared    buffers     cached
Mem:       1918576    1264576     654000          0      62952     159112
-/+ buffers/cache:    1042512     876064
Swap:      4128760          0    4128760
 
四 总结
 
1. NGINX平均每个连接的内存占用很小,通过ps的rss看出,每个连接物理内存占用约1k。多数内存都被内核TCP缓存占用。
2. NGINX维持大量连接(少量活跃连接,本文中平均每秒活跃连接为总连接数的千分之一)占用很少CPU,上文仅为2%。
3. 最好的优化就是不优化。整个测试除了提升文件数和连接数的这些硬限制外,没有任何参数调优,但仔细计算下就发现平均每个连接内存占用不到10k,远小于默认的缓存大小(net.ipv4.tcp_rmem = 4096     87380     4194304)和 (net.ipv4.tcp_wmem = 4096     16384     4194304)
4. NGINX维持此类连接的主要瓶颈就是可用内存大小,我的2GB内存虚拟机其实可以支持15万长连接,只不过我物理机器没有内存再继续clone虚拟机客户端了:-(
5. 虽然会遇到更多内核参数的限制,但大内存服务器支持100万连接是完全没问题的。
如何联系我:【万里虎】www.bravetiger.cn 【QQ】3396726884 (咨询问题100元起,帮助解决问题500元起) 【博客】http://www.cnblogs.com/kenshinobiy/
目录
打赏
0
0
0
0
24
分享
相关文章
如何在 CentOS 7 上为 Nginx 创建自签名 SSL 证书
如何在 CentOS 7 上为 Nginx 创建自签名 SSL 证书
269 1
场景题:有40亿个QQ号如何去重?仅1GB内存
在处理大数据去重问题时,如40亿QQ号的去重(仅1GB内存),可采用Bitmap和布隆过滤器两种方法。Bitmap利用位图存储,每个QQ号占1位,总需512MB内存,适用于整型数据;布隆过滤器通过多个哈希函数计算下标,适合字符串或对象去重,但存在误判率。在线人员统计等场景也可使用类似思路,将ID作为偏移值标记在线状态或视频存在性。
44 2
|
1月前
|
centos 中查看 内存及磁盘使用率
通过这些命令,您可以全面了解系统资源的使用情况,从而更好地管理和优化系统。
156 22
nginx修改网站默认根目录及发布(linux、centos、ubuntu)openEuler软件源repo站点
通过合理配置 Nginx,我们可以高效地管理和发布软件源,为用户提供稳定可靠的服务。
279 13
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
4月前
|
处理40亿个QQ号的挑战:如何在1GB内存中实现高效管理
在大数据时代,如何高效管理和处理海量数据是每个开发者和数据工程师面临的挑战。以40亿个QQ号为例,如何在仅有1GB内存的条件下完成数据的存储、查询和处理,成为了一个值得深入探讨的问题。本文将分享一些有效的策略和技术,帮助你在内存受限的情况下高效处理海量数据。
66 3
1GB内存挑战:高效处理40亿QQ号的策略
在面对如何处理40亿个QQ号仅用1GB内存的难题时,我们需要采用一些高效的数据结构和算法来优化内存使用。这个问题涉及到数据存储、查询和处理等多个方面,本文将分享一些实用的技术策略,帮助你在有限的内存资源下处理大规模数据集。
58 1
“四两拨千斤” —— 1.2MB 数据如何吃掉 10GB 内存
一个特殊请求引发服务器内存用量暴涨进而导致进程 OOM 的惨案。
140 14
2022年超详细在CentOS 7上安装Nginx方法(源码安装)
这篇文章提供了在CentOS 7系统上通过源码安装Nginx的详细步骤,包括从官网下载Nginx源码包、上传至虚拟机、解压、删除压缩包、编译安装前的配置、安装PCRE库(因为Nginx使用PCRE库解析正则表达式)、安装zlib和OpenSSL库(用于支持HTTPS协议)、重新编译Nginx、安装后启动Nginx服务、关闭服务、修改默认端口、以及重启服务测试等步骤。文章还提供了相关命令和操作截图,帮助用户更好地理解和执行安装过程。
2022年超详细在CentOS 7上安装Nginx方法(源码安装)
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等