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/
目录
相关文章
|
应用服务中间件 Linux 网络安全
Centos 8.0中Nginx配置文件和https正书添加配置
这是一份Nginx配置文件,包含HTTP与HTTPS服务设置。主要功能如下:1) 将HTTP(80端口)请求重定向至HTTPS(443端口),增强安全性;2) 配置SSL证书,支持TLSv1.1至TLSv1.3协议;3) 使用uWSGI与后端应用通信(如Django);4) 静态文件托管路径设为`/root/code/static/`;5) 定制错误页面(404、50x)。适用于Web应用部署场景。
1243 87
|
人工智能 边缘计算 自然语言处理
普通电脑也能跑AI:10个8GB内存的小型本地LLM模型推荐
随着模型量化技术的发展,大语言模型(LLM)如今可在低配置设备上高效运行。本文介绍本地部署LLM的核心技术、主流工具及十大轻量级模型,探讨如何在8GB内存环境下实现高性能AI推理,涵盖数据隐私、成本控制与部署灵活性等优势。
10732 0
普通电脑也能跑AI:10个8GB内存的小型本地LLM模型推荐
|
数据采集 编解码 人工智能
Gemma 3n正式版开源:谷歌全新端侧多模态大模型,2GB 内存就能跑,重点提升编码和推理能力!
6月底,Google正式开源发布了全新端侧多模态大模型 Gemma 3n!相较此前的预览版,最新的 Gemma 3n 完整版进一步提升性能表现,支持在 2GB 内存的硬件上本地运行,重点提升了编码和推理方面的能力。
1561 1
|
应用服务中间件 Linux 网络安全
技术指南:如何把docsify项目部署到基于CentOS系统的Nginx中。
总结 与其他部署方法相比,将docsify项目部署到基于CentOS系统的Nginx中比较简单。以上步骤应当帮助你在不花费太多时间的情况下,将你的项目顺利部署到Nginx中。迈出第一步,开始部署你的docsify项目吧!
584 14
|
编解码 Ubuntu Linux
ubuntu系统安装指南:免费且适合老旧电脑,4GB内存也能流畅运行!
点击启动台,找到并点击设置。在设置中,选择语言和区域,再点击管理语言。安装所需的语言包,输入密码进行确认。等待大约2分钟,语言包安装完成后,点击安装语言,选择中文选项。这里有简体和繁体两种选择,根据个人需求进行选择。再次等待2分钟,安装完成后,点击这里,选择中文并应用。然后,将出现的中文拖动到最上面,应用更改并退出设置。最后,重启虚拟机,再次进入系统时,你会发现界面已经变成了中文,而且系统依然保持流畅。Ubuntu系统不仅外观漂亮、干净,而且性能稳定、安全可靠。如果你的电脑内存只有4GB,或者你对Windows系统感到厌倦,那么Ubuntu绝对是一个值得尝试的选择。它不仅办公打印一应俱全,还拥
|
负载均衡 算法 应用服务中间件
Nginx长连接负载均衡详细说明以及案例
本文详细介绍了Nginx长连接负载均衡的配置与原理。长连接(Keepalive)允许客户端和服务器保持连接,减少建立和关闭连接的开销。Nginx支持多种负载均衡算法,如轮询、IP哈希等。通过在Nginx配置文件中使用`upstream`模块和`keepalive`指令,可以实现长连接负载均衡,从而提高系统的性能和响应速度。示例配置展示了如何设置后端服务器组、长连接数及HTTP/1.1协议,确保连接复用,降低延迟。
961 5
|
存储 大数据 BI
场景题:有40亿个QQ号如何去重?仅1GB内存
在处理大数据去重问题时,如40亿QQ号的去重(仅1GB内存),可采用Bitmap和布隆过滤器两种方法。Bitmap利用位图存储,每个QQ号占1位,总需512MB内存,适用于整型数据;布隆过滤器通过多个哈希函数计算下标,适合字符串或对象去重,但存在误判率。在线人员统计等场景也可使用类似思路,将ID作为偏移值标记在线状态或视频存在性。
693 5
|
负载均衡 Ubuntu 应用服务中间件
nginx修改网站默认根目录及发布(linux、centos、ubuntu)openEuler软件源repo站点
通过合理配置 Nginx,我们可以高效地管理和发布软件源,为用户提供稳定可靠的服务。
2671 13
|
监控 算法 应用服务中间件
“四两拨千斤” —— 1.2MB 数据如何吃掉 10GB 内存
一个特殊请求引发服务器内存用量暴涨进而导致进程 OOM 的惨案。
538 14
|
开发框架 监控 .NET
【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
514 5