[問題] Ningx High Concurrent求解

看板Linux作者 (None)時間11年前 (2014/10/17 10:58), 編輯推噓1(1047)
留言48則, 4人參與, 最新討論串1/1
手邊有一台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.htmlb60413:轉錄至看板 PHP 10/17 10:58

10/17 14:33, , 1F
MSL是寫死在kernel的 這值除非重新compile不然調不了
10/17 14:33, 1F

10/17 14:34, , 2F
不過可以調整減輕狀況 net.ipv4.tcp_tw_recycle
10/17 14:34, 2F

10/17 14:34, , 3F
net.ipv4.tcp_tw_reuse 這兩個設成 1
10/17 14:34, 3F

10/17 14:35, , 4F
看來已經調整了XD
10/17 14:35, 4F

10/17 14:39, , 5F
然後tcp_max_tw_buckets不該調低
10/17 14:39, 5F

10/17 14:39, , 6F
這會讓TIME_WAIT允許數量嚴重不足
10/17 14:39, 6F

10/17 14:43, , 7F
痾... 說錯 tcp_max_tw_buckets 還不夠高
10/17 14:43, 7F

10/17 15:29, , 8F
有試著將tcp_max_tw_buckets調整到10000
10/17 15:29, 8F

10/17 15:29, , 9F
發現伺服器回應的時間變長了, ab還是無法送完一萬個請求
10/17 15:29, 9F

10/17 15:30, , 10F
並且發送成功的請求數量降低了
10/17 15:30, 10F

10/17 16:04, , 11F
不過我自己-c1000都能正常過-n10000了
10/17 16:04, 11F

10/17 16:05, , 12F
不管kernel還是nginx參數都沒調過...
10/17 16:05, 12F

10/17 16:10, , 13F
如果是這樣的話, 會跟軟、硬體防火牆有比較大的關係嗎?
10/17 16:10, 13F

10/17 16:11, , 14F
已經在網路上查過各式的調整法, 也都實際試過, 一直無解..
10/17 16:11, 14F

10/17 16:13, , 15F
手上幾台商用 web 提供大量連線對外方式,一般作法
10/17 16:13, 15F

10/17 16:13, , 16F
不是一台撐起全部服務,大多會分散提供大量存取
10/17 16:13, 16F

10/17 16:13, , 17F
有考慮虛擬化技術方式分散嗎?高檔 server 不用這個
10/17 16:13, 17F

10/17 16:14, , 18F
東西其實 cpu 算是相當閒置沒有被大量利用到
10/17 16:14, 18F

10/17 16:16, , 19F
虛擬化之後 os 本身這類網路負荷問題也可以得以舒緩
10/17 16:16, 19F

10/17 16:20, , 20F
願意試看看, kenduest可以提供相關簡易的資訊嗎? 謝謝
10/17 16:20, 20F

10/17 16:22, , 21F
你可以網路上爬文一下,目前 linux 都用 kvm 虛擬化技術
10/17 16:22, 21F

10/17 16:22, , 22F
ubuntu or rh-based 等 linux 版本網路上都很多資訊
10/17 16:22, 22F

10/17 16:23, , 23F
不過後續你要搭配其他方式來 loading balance
10/17 16:23, 23F

10/17 16:23, , 24F
跑 bridge 網路架構,透過其他硬體平衡負載器分散存取
10/17 16:23, 24F

10/17 16:24, , 25F
或者是 nat 模式你還要搭配 iptables nat 設定功能
10/17 16:24, 25F

10/17 16:24, , 26F
目前是希望可以先將單台伺服器設置好, 才會去做附載平衡
10/17 16:24, 26F

10/17 16:24, , 27F
原本以為設備比較好的機器, 應該有辦法負載這麼大的請求
10/17 16:24, 27F

10/17 16:25, , 28F
或者是搭配 nginx 的 proxy 方式提供分散到多台虛擬機
10/17 16:25, 28F

10/17 16:25, , 29F
所以才希望試看看, 是否可以單純修改設定就達到一定的成果
10/17 16:25, 29F

10/17 16:25, , 30F
這並非是因為你系統的 cpu or memory 多就可以解決問題
10/17 16:25, 30F

10/17 16:27, , 31F
目前測試時, 都是使用Virtual Box創建測試機
10/17 16:27, 31F

10/17 16:27, , 32F
請問這算是你說的KVM技術嗎?
10/17 16:27, 32F

10/17 16:30, , 33F
virtualbox 是一個 vm 實作的軟體,商業的 server 服務
10/17 16:30, 33F

10/17 16:31, , 34F
沒會去用這個提供實際服務,linux kvm 比較可靠
10/17 16:31, 34F

10/17 17:39, , 35F
樓上... 你用iptables nginx都不重要
10/17 17:39, 35F

10/17 17:39, , 36F
現在問題是他的kernel就是吃不下那連線數
10/17 17:39, 36F

10/17 17:40, , 37F
後端分散了 負責分散的前端連線問題還是在啊
10/17 17:40, 37F

10/17 18:19, , 38F
問個問題,有沒有想過是 client 端自己的問題
10/17 18:19, 38F

10/17 18:19, , 39F
若你測試端都是固定一台機器的話,那 client 端也會導致
10/17 18:19, 39F

10/17 18:21, , 40F
因為過多的 TIME_WAIT 會導致無法正常連線存取
10/17 18:21, 40F

10/17 18:23, , 41F
至於平衡負載架構,前端是有所謂瓶頸問題,但是
10/17 18:23, 41F

10/17 18:24, , 42F
NAT 那邊是另外一個處理單純自己連線的諭時問題
10/17 18:24, 42F

10/17 18:25, , 43F
分散可以先減低單一台 WEB server 本身 TIME_WAIT 問題
10/17 18:25, 43F

10/17 18:26, , 44F
分散還有其他方式,像是 DNS 分散架構
10/17 18:26, 44F

10/17 18:28, , 45F
所以 dns balance + l4 balancer + multi server 分散
10/17 18:28, 45F

10/17 18:29, , 46F
不過好像與原貼問題已經沒很直接關係了
10/17 18:29, 46F

10/17 18:30, , 47F
這篇另外也討論到相關議題: http://goo.gl/wllY3P
10/17 18:30, 47F

10/20 09:44, , 48F
ab 自己要打到那麼高也不是件容易的事
10/20 09:44, 48F
文章代碼(AID): #1KG8Mwbz (Linux)
文章代碼(AID): #1KG8Mwbz (Linux)