[問題] Ningx High Concurrent求解

[b60413 (None)]

手邊有一台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://www.ptt.cc/bbs/Linux/M.1413514682.A.97D.html
※ b60413:轉錄至看板 PHP                                           10/17 10:58
→ danny8376: MSL是寫死在kernel的 這值除非重新compile不然調不了
→ danny8376: 不過可以調整減輕狀況 net.ipv4.tcp_tw_recycle
→ danny8376: net.ipv4.tcp_tw_reuse 這兩個設成 1
→ danny8376: 看來已經調整了XD
→ danny8376: 然後tcp_max_tw_buckets不該調低
→ danny8376: 這會讓TIME_WAIT允許數量嚴重不足
→ danny8376: 痾... 說錯 tcp_max_tw_buckets 還不夠高
→ b60413: 有試著將tcp_max_tw_buckets調整到10000
→ b60413: 發現伺服器回應的時間變長了, ab還是無法送完一萬個請求
→ b60413: 並且發送成功的請求數量降低了
→ danny8376: 不過我自己-c1000都能正常過-n10000了
→ danny8376: 不管kernel還是nginx參數都沒調過...
→ b60413: 如果是這樣的話, 會跟軟、硬體防火牆有比較大的關係嗎?
→ b60413: 已經在網路上查過各式的調整法, 也都實際試過, 一直無解..
→ kenduest: 手上幾台商用 web 提供大量連線對外方式，一般作法
→ kenduest: 不是一台撐起全部服務，大多會分散提供大量存取
→ kenduest: 有考慮虛擬化技術方式分散嗎？高檔 server 不用這個
→ kenduest: 東西其實 cpu 算是相當閒置沒有被大量利用到
→ kenduest: 虛擬化之後 os 本身這類網路負荷問題也可以得以舒緩
→ b60413: 願意試看看, kenduest可以提供相關簡易的資訊嗎? 謝謝
→ kenduest: 你可以網路上爬文一下，目前 linux 都用 kvm 虛擬化技術
→ kenduest: ubuntu or rh-based 等 linux 版本網路上都很多資訊
→ kenduest: 不過後續你要搭配其他方式來 loading balance
→ kenduest: 跑 bridge 網路架構，透過其他硬體平衡負載器分散存取
→ kenduest: 或者是 nat 模式你還要搭配 iptables nat 設定功能
→ b60413: 目前是希望可以先將單台伺服器設置好, 才會去做附載平衡
→ b60413: 原本以為設備比較好的機器, 應該有辦法負載這麼大的請求
→ kenduest: 或者是搭配 nginx 的 proxy 方式提供分散到多台虛擬機
→ b60413: 所以才希望試看看, 是否可以單純修改設定就達到一定的成果
→ kenduest: 這並非是因為你系統的 cpu or memory 多就可以解決問題
→ b60413: 目前測試時, 都是使用Virtual Box創建測試機
→ b60413: 請問這算是你說的KVM技術嗎?
→ kenduest: virtualbox 是一個 vm 實作的軟體，商業的 server 服務
→ kenduest: 沒會去用這個提供實際服務，linux kvm 比較可靠
→ danny8376: 樓上... 你用iptables nginx都不重要
→ danny8376: 現在問題是他的kernel就是吃不下那連線數
→ danny8376: 後端分散了 負責分散的前端連線問題還是在啊
→ kenduest: 問個問題，有沒有想過是 client 端自己的問題
→ kenduest: 若你測試端都是固定一台機器的話，那 client 端也會導致
→ kenduest: 因為過多的 TIME_WAIT 會導致無法正常連線存取
→ kenduest: 至於平衡負載架構，前端是有所謂瓶頸問題，但是
→ kenduest: NAT 那邊是另外一個處理單純自己連線的諭時問題
→ kenduest: 分散可以先減低單一台 WEB server 本身 TIME_WAIT 問題
→ kenduest: 分散還有其他方式，像是 DNS 分散架構
→ kenduest: 所以 dns balance + l4 balancer + multi server 分散
→ kenduest: 不過好像與原貼問題已經沒很直接關係了
→ kenduest: 這篇另外也討論到相關議題: http://goo.gl/wllY3P
推 newsp: ab 自己要打到那麼高也不是件容易的事