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

2024-09-09 03:58

本文主要是介绍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发挥这个优点。本文做一个简单测试,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万连接是完全没问题的。 

这篇关于NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1150097

相关文章

Python中bisect_left 函数实现高效插入与有序列表管理

《Python中bisect_left函数实现高效插入与有序列表管理》Python的bisect_left函数通过二分查找高效定位有序列表插入位置,与bisect_right的区别在于处理重复元素时... 目录一、bisect_left 基本介绍1.1 函数定义1.2 核心功能二、bisect_left 与

MySQL 表的内外连接案例详解

《MySQL表的内外连接案例详解》本文给大家介绍MySQL表的内外连接,结合实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录表的内外连接(重点)内连接外连接表的内外连接(重点)内连接内连接实际上就是利用where子句对两种表形成的笛卡儿积进行筛选,我

Spring中管理bean对象的方式(专业级说明)

《Spring中管理bean对象的方式(专业级说明)》在Spring框架中,Bean的管理是核心功能,主要通过IoC(控制反转)容器实现,下面给大家介绍Spring中管理bean对象的方式,感兴趣的朋... 目录1.Bean的声明与注册1.1 基于XML配置1.2 基于注解(主流方式)1.3 基于Java

CentOS 7 YUM源配置错误的解决方法

《CentOS7YUM源配置错误的解决方法》在使用虚拟机安装CentOS7系统时,我们可能会遇到YUM源配置错误的问题,导致无法正常下载软件包,为了解决这个问题,我们可以替换YUM源... 目录一、备份原有的 YUM 源配置文件二、选择并配置新的 YUM 源三、清理旧的缓存并重建新的缓存四、验证 YUM 源

基于Python+PyQt5打造一个跨平台Emoji表情管理神器

《基于Python+PyQt5打造一个跨平台Emoji表情管理神器》在当今数字化社交时代,Emoji已成为全球通用的视觉语言,本文主要为大家详细介绍了如何使用Python和PyQt5开发一个功能全面的... 目录概述功能特性1. 全量Emoji集合2. 智能搜索系统3. 高效交互设计4. 现代化UI展示效果

Windows 系统下 Nginx 的配置步骤详解

《Windows系统下Nginx的配置步骤详解》Nginx是一款功能强大的软件,在互联网领域有广泛应用,简单来说,它就像一个聪明的交通指挥员,能让网站运行得更高效、更稳定,:本文主要介绍W... 目录一、为什么要用 Nginx二、Windows 系统下 Nginx 的配置步骤1. 下载 Nginx2. 解压

Apache 高级配置实战之从连接保持到日志分析的完整指南

《Apache高级配置实战之从连接保持到日志分析的完整指南》本文带你从连接保持优化开始,一路走到访问控制和日志管理,最后用AWStats来分析网站数据,对Apache配置日志分析相关知识感兴趣的朋友... 目录Apache 高级配置实战:从连接保持到日志分析的完整指南前言 一、Apache 连接保持 - 性

Mysql中的用户管理实践

《Mysql中的用户管理实践》:本文主要介绍Mysql中的用户管理实践,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录13. 用户管理13.1 用户 13.1.1 用户信息 13.1.2 创建用户 13.1.3 删除用户 13.1.4 修改用户

电脑蓝牙连不上怎么办? 5 招教你轻松修复Mac蓝牙连接问题的技巧

《电脑蓝牙连不上怎么办?5招教你轻松修复Mac蓝牙连接问题的技巧》蓝牙连接问题是一些Mac用户经常遇到的常见问题之一,在本文章中,我们将提供一些有用的提示和技巧,帮助您解决可能出现的蓝牙连接问... 蓝牙作为一种流行的无线技术,已经成为我们连接各种设备的重要工具。在 MAC 上,你可以根据自己的需求,轻松地

宝塔安装的MySQL无法连接的情况及解决方案

《宝塔安装的MySQL无法连接的情况及解决方案》宝塔面板是一款流行的服务器管理工具,其中集成的MySQL数据库有时会出现连接问题,本文详细介绍两种最常见的MySQL连接错误:“1130-Hostisn... 目录一、错误 1130:Host ‘xxx.xxx.xxx.xxx’ is not allowed