作者b60413 (None)
看板Linux
标题[问题] Ningx High Concurrent求解
时间Fri Oct 17 10:57:58 2014
手边有一台Server, 设备大概是16G, 16 Core CPU,
打算拿来建置一台Backend Web Server(只跑PHP),
套件部分使用Nginx(0.8.6)、PHP-fpm,
希望可以达到每秒钟并发数在200~500之间,
实际架设後并使用ApacheBench测试(-n10000 -c200)的结果是,
只要当系统的TIME_WAIT达到6000(net.ipv4.tcp_max_tw_buckets)之後,
伺服器的反应开始下降(使用tshark观察), 并且就卡住了,
最後ab会发出apr_socket_recv: Connection timed out (110)的讯息,
尤其反覆测试後, 在先前的TIME_WAIT释放之前, Server都会处於非常慢的状况,
请问有哪些细节是没有注意到还可以持续优化的吗?
还是这台机器的等级, 没有办法处理这麽高并发的数量?
中间, 有使用ss去观察TIME_WAIT的timer倒数,
发现每次都是从60秒开始倒数,
请问有办法降低这个数值吗?
或者让Nginx的连接在client关闭後,
直接将该资源回收掉吗?
目前一直着眼在TIME_WAIT的问题,
是否我思考的方向有错?
还请有经验的指点迷津,
感谢.
kernel参数调整如下,
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_mem = 786432 10485760 15728640
net.ipv4.tcp_wmem = 4096 10485760 20971520
net.core.wmem_max = 20971520
net.ipv4.tcp_rmem = 4096 10485760 20971520
net.core.rmem_max = 20971520
/etc/limits.conf调整如下,
* soft nofile 65535
* hard nofile 65535
Ningx的主要相关设定如下,
worker_processes 8;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 51200;
}
PHP-fpm的主要相关设定如下,
backlog = 8192
max_children = 256(static)
rlimit_files = 65535
--
http://www.myspace.com/soundtrack0220
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 140.126.4.12
※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Linux/M.1413514682.A.97D.html
※ b60413:转录至看板 PHP 10/17 10:58
1F：→ danny8376: MSL是写死在kernel的 这值除非重新compile不然调不了 10/17 14:33
2F：→ danny8376: 不过可以调整减轻状况 net.ipv4.tcp_tw_recycle 10/17 14:34
3F：→ danny8376: net.ipv4.tcp_tw_reuse 这两个设成 1 10/17 14:34
4F：→ danny8376: 看来已经调整了XD 10/17 14:35
5F：→ danny8376: 然後tcp_max_tw_buckets不该调低 10/17 14:39
6F：→ danny8376: 这会让TIME_WAIT允许数量严重不足 10/17 14:39
7F：→ danny8376: 痾... 说错 tcp_max_tw_buckets 还不够高 10/17 14:43
8F：→ b60413: 有试着将tcp_max_tw_buckets调整到10000 10/17 15:29
9F：→ b60413: 发现伺服器回应的时间变长了, ab还是无法送完一万个请求 10/17 15:29
10F：→ b60413: 并且发送成功的请求数量降低了 10/17 15:30
11F：→ danny8376: 不过我自己-c1000都能正常过-n10000了 10/17 16:04
12F：→ danny8376: 不管kernel还是nginx参数都没调过... 10/17 16:05
13F：→ b60413: 如果是这样的话, 会跟软、硬体防火墙有比较大的关系吗? 10/17 16:10
14F：→ b60413: 已经在网路上查过各式的调整法, 也都实际试过, 一直无解.. 10/17 16:11
15F：→ kenduest: 手上几台商用 web 提供大量连线对外方式，一般作法 10/17 16:13
16F：→ kenduest: 不是一台撑起全部服务，大多会分散提供大量存取 10/17 16:13
17F：→ kenduest: 有考虑虚拟化技术方式分散吗？高档 server 不用这个 10/17 16:13
18F：→ kenduest: 东西其实 cpu 算是相当闲置没有被大量利用到 10/17 16:14
19F：→ kenduest: 虚拟化之後 os 本身这类网路负荷问题也可以得以舒缓 10/17 16:16
20F：→ b60413: 愿意试看看, kenduest可以提供相关简易的资讯吗? 谢谢 10/17 16:20
21F：→ kenduest: 你可以网路上爬文一下，目前 linux 都用 kvm 虚拟化技术 10/17 16:22
22F：→ kenduest: ubuntu or rh-based 等 linux 版本网路上都很多资讯 10/17 16:22
23F：→ kenduest: 不过後续你要搭配其他方式来 loading balance 10/17 16:23
24F：→ kenduest: 跑 bridge 网路架构，透过其他硬体平衡负载器分散存取 10/17 16:23
25F：→ kenduest: 或者是 nat 模式你还要搭配 iptables nat 设定功能 10/17 16:24
26F：→ b60413: 目前是希望可以先将单台伺服器设置好, 才会去做附载平衡 10/17 16:24
27F：→ b60413: 原本以为设备比较好的机器, 应该有办法负载这麽大的请求 10/17 16:24
28F：→ kenduest: 或者是搭配 nginx 的 proxy 方式提供分散到多台虚拟机 10/17 16:25
29F：→ b60413: 所以才希望试看看, 是否可以单纯修改设定就达到一定的成果 10/17 16:25
30F：→ kenduest: 这并非是因为你系统的 cpu or memory 多就可以解决问题 10/17 16:25
31F：→ b60413: 目前测试时, 都是使用Virtual Box创建测试机 10/17 16:27
32F：→ b60413: 请问这算是你说的KVM技术吗? 10/17 16:27
33F：→ kenduest: virtualbox 是一个 vm 实作的软体，商业的 server 服务 10/17 16:30
34F：→ kenduest: 没会去用这个提供实际服务，linux kvm 比较可靠 10/17 16:31
35F：→ danny8376: 楼上... 你用iptables nginx都不重要 10/17 17:39
36F：→ danny8376: 现在问题是他的kernel就是吃不下那连线数 10/17 17:39
37F：→ danny8376: 後端分散了 负责分散的前端连线问题还是在啊 10/17 17:40
38F：→ kenduest: 问个问题，有没有想过是 client 端自己的问题 10/17 18:19
39F：→ kenduest: 若你测试端都是固定一台机器的话，那 client 端也会导致 10/17 18:19
40F：→ kenduest: 因为过多的 TIME_WAIT 会导致无法正常连线存取 10/17 18:21
41F：→ kenduest: 至於平衡负载架构，前端是有所谓瓶颈问题，但是 10/17 18:23
42F：→ kenduest: NAT 那边是另外一个处理单纯自己连线的谕时问题 10/17 18:24
43F：→ kenduest: 分散可以先减低单一台 WEB server 本身 TIME_WAIT 问题 10/17 18:25
44F：→ kenduest: 分散还有其他方式，像是 DNS 分散架构 10/17 18:26
45F：→ kenduest: 所以 dns balance + l4 balancer + multi server 分散 10/17 18:28
46F：→ kenduest: 不过好像与原贴问题已经没很直接关系了 10/17 18:29
48F：推 newsp: ab 自己要打到那麽高也不是件容易的事 10/20 09:44