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万连接是完全没问题的。 

时间: 2024-10-11 21:34:23

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

NGINX轻松管理10万长连接

一 前言 当管理大量连接时,特别是只有少量活跃连接,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 内核参数调整: $ /sb

使用SuperSocket打造逾10万长连接的Socket服务

SuperSocket 是一个轻量级, 跨平台而且可扩展的 .Net/Mono Socket 服务器程序框架.你无须了解如何使用 Socket, 如何维护 Socket 连接和 Socket 如何工作,但是你却可以使用 SuperSocket 很容易的开发出一款 Socket 服务器端软件,例如游戏服务器,GPS 服务器, 工业控制服务和数据采集服务器等等. PS:上面这句话复制官网的,好了,总之告诉大家SuperSocket已经很强大.很稳定.方便. 如果你没有Socket基础,首先要了解协议

nginx优化 实现10万并发访问量

一般来说nginx配置文件中对优化比较有作用的为以下几项:worker_processes 8;1 nginx进程数,建议按照cpu数目来指定,一般为它的倍数.worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 0010000001000000 10000000;为每个进程分配 cpu,上例中将 8 个进程分配到 8 个 cpu,当然可以写多个,或者将一个进程分配到多个cpu.worker_rlimit_nofile

Nginx Upstream Keepalive 分析 保持长连接

相关配置 Nginx Upstream长连接由upstream模式下的keepalive指令控制,并指定可用于长连接的连接数,配置样例如下: upstream http_backend {     server 127.0.0.1:8080;       keepalive 16; }   server {     ...       location /http/ {         proxy_pass http://http_backend;         proxy_http_vers

服务器单机保持长连接50万+

最近在做一个保持手机长在线的业务,设计要求支持手机长连接100万上,当前我们只做了一个单机版本,未开发集群版本. 硬件:2U * 8C * 2.4G, 16G MEM, Raid5.软件:操作系统是LINUX RHEL 5.5 64x,JDK1.6_30 64x,还有MySQL 5.5 64x. 程序使用JAVA开发,用了Netty NIO框架.大家知道,一个JVM启动的线程数有限,也就几万,如果用传统的IO,一个连接要启动两个线程,一读一写,50万连接就是100万线程,这与JAVA虚拟机的能力

Nginx与Tomcat、Client之间请求的长连接配置不一致问题解决[转]

http://bert82503.iteye.com/blog/2152613 前些天,线上出现“服务端长连接与客户端短连接引起Nginx的Writing.Active连接数过高问题”,这个是由于“服务端使用HTTPs长连接,而客户端使用短连接”引起.这几天,发现Nginx与Tomcat之间也存在同样的问题,原因是两边的相关配置参数不一致引起的.(这是心细活!) 先说说服务为什么使用HTTPs长连接技术?有如下几个原因: 对响应时间要求较高: 服务走的是公网,客户端与服务端的TCP建立的三次握手

nginx之旅(第六篇):nginx优化--nginx优化目的、工作进程优化、长连接设置、数据压缩、客户端缓存

一.Nginx优化目的 标准情况下,软件默认的参数都是对安装软件的硬件标准来设置的,目前我们服务?的硬件资源远远大于要求的标准,所以为了让服务?性能更加出众,充分利用服务?的硬件资源,我们一般需要优化APP的并发数来提升服务器?的性能. 二.工作进程优化 1) worker_processes worker_processes指Nginx的工作进程,这个值是直接受到服务器CPU核数量影响的(当然也有其他影响),Nginx默认配置为auto,意思是会自动检测CPU核做修改,建议worker_pro

基于管道通知的百万并发长连接server模型

0.前言 最近突然想了解怎样设计一个支持百万连接的后台server架构. 要设计一个支持百万连接的后台server,我们首先要知道会有哪些因素限制后台server的高并发连接,这里想到的因素有以下几点: 1.操作系统的参数设置能否支持百万并发连接: 2.操作系统维持百万并发长连接需要多少内存: 3.应用层面上维持百万并发长连接需要多少内存: 4.百万并发长连接的吞吐量是否超过了硬件网卡的限制. 在学习的过程中,主要针对的是1.2.4,第3点一般跟业务相关,这里暂时没有考虑. 本篇文章估计需要多次

[转]HTTP的长连接和短连接

本文原链接:http://www.cnblogs.com/cswuyg/p/3653263.html   本文总结&分享网络编程中涉及的长连接.短连接概念.     关键字:Keep-Alive,并发连接数限制,TCP,HTTP 一.什么是长连接 HTTP1.1规定了默认保持长连接(HTTP persistent connection ,也有翻译为持久连接),数据传输完成了保持TCP连接不断开(不发RST包.不四次握手),等待在同域名下继续用这个通道传输数据:相反的就是短连接. HTTP首部的C