2012-08-18 91 views
7

我正在處理一個有點不同尋常的應用程序,其中10k個客戶端都準確定時以嘗試一次提交數據,每3分鐘左右一次。這種「AB」命令相當準確地模擬現實世界中的一個彈幕:Node.js處理大量併發連接

ab -c 10000 -n 10000 -r "http://example.com/submit?data=foo" 

我在rackspacecloud如何使用Node.js在Ubuntu 12.4 VPS實例來收集這些意見,但是,我看到了一些非常奇怪的行爲,即使我刪除了所有的業務邏輯並將http請求變爲空操作。

當測試完成大約90%時,它會長時間掛起。奇怪的是,這種情況始終發生在90% - 對於c = n = 10k,在9000;對於c = n = 5k,爲4500;對於C = n = 2k,在1800.測試實際上最終完成,通常沒有錯誤。但ab和節點日誌都顯示連續處理,直到測試運行的大約80-90%,然後在完成之前進行長時間的停頓。

當節點正常處理請求時,CPU使用率通常在50-70%左右。在掛起期間,CPU達到100%。有時它保持接近0.在不穩定的CPU響應和它與實際連接數量似乎無關的事實之間(只有%完成),我不懷疑垃圾收集器。

我試過這個在localhost和遠程服務器上運行'ab' - 效果相同。

我懷疑與TCP堆棧有關的事情,可能涉及關閉連接,但是沒有任何配置更改有幫助。我的變化:

  • 的ulimit -n 999999
  • 當我聽(),我積壓設置爲10000

sysctl的變化是:

net.core.rmem_max = 16777216 
net.core.wmem_max = 16777216 
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216 
net.ipv4.tcp_max_orphans = 20000 
net.ipv4.tcp_max_syn_backlog = 10000 
net.core.somaxconn = 10000 
net.core.netdev_max_backlog = 10000 

我也注意到,我傾向於在內核日誌中獲取此信息:

TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters. 

我對這個msg感到困惑,因爲TCP backlog隊列應該足夠深到永遠不會溢出。如果我禁用syn cookie,則「發送cookie」會轉到「Dropping connections」。

我推測這是某種Linux TCP堆棧調整問題,我已經閱讀了幾乎所有可以在網上找到的東西。我所嘗試的任何東西似乎都很重要。有什麼建議?

更新:試圖與tcp_max_syn_backlog,SOMAXCONN,netdev_max_backlog,和聽()積壓的參數組,以50K與行爲沒有任何變化。仍然會產生SYN洪水警報。

+1

在一個側面說明,我的最終解決方案很感興趣,這是我需要大量的活動連接的NodeJS也。 –

+1

對於它的價值,高效的節點就可以了,10K連接所有做的事情,在一次更比負載我會離開到一個VPS。 – Brad

回答

3

你在運行節點的同一臺機器上運行ab嗎?如果沒有,你有1G或10G網卡?如果你是,那麼你真的不想處理20,000個開放連接嗎?

另外,如果您將net.core.somaxconn更改爲10,000,那麼您絕對沒有在該機器上打開其他套接字?如果你這樣做,那麼10,000就不夠高。

您是否嘗試過使用nodejs羣集來分散每個進程的打開連接數?

+0

我已經從本地主機上,並從另一臺機器上運行AB。兩種情況都表現出相同的暫停行爲,儘管測試在本地主機上運行得更快。暫停行爲發生具有8K和5K測試(以及與2K測試程度較輕),但我會重新運行與SOMAXCONN集測試,以50K。我不打算使用這些機器的冗餘和負載均衡集羣,但這個測試是要弄清楚有多少情況下,我都需要。 – stickfigure

+0

我已經運行與參數測試設置爲50K和行爲是不變。最令我驚訝的是SYN洪水警告;積壓設置爲50k,我不希望溢出隊列。 – stickfigure

+0

@stickfigure看看這個答案http://serverfault.com/questions/294209/possible-syn-flooding-in-log-despite-low-number-of-syn-recv-connections –