2011-12-21 36 views
2

我喜歡node.js的事件觸發的模式,但是隻需要你到目前爲止 - 當你有一個函數(比如HTTP連接請求處理程序),做了許多繁重的工作在CPU上,它仍然是‘堵’直到它的函數返回。這是可以預料的。但是如果我想平衡這一點,那麼使用操作系統安排流程的能力,給定請求需要更長時間才能處理,但整體響應時間會更短?分叉更多的工人可以讓我平衡CPU繁重的工作嗎?

我的生產代碼使用節點的非常簡單的集羣模塊到餐桌多名工人等於核心系統的CPU擁有的數量。分叉比這更糟 - 每個核心可能有兩三名工人?我知道這裏會有內存開銷,但內存不是我的限制。我所做的閱讀提到你想避免「超額訂閱」,但是在現代系統中肯定會有兩到三個進程在處理器上爭奪時間,所以你不會發瘋。

回答

3

我認爲你的想法聽起來像是不錯的一個;特別是因爲許多處理器支持hyperthreading。超線程是神奇而不會突然增加一倍,你的應用程序的速度和吞吐量,但它可以意義的有另一個線程準備一個核心來執行時,第一個線程需要等待填補的內存請求。

當你啓動多個worker時要小心:Linux內核確實傾向於保持進程在整個生命週期內在同一個處理器上執行,以提供強大的高速緩存親和性。這很有道理。但我見過幾個消耗CPU的進程爭奪一個核心還是差了一個超線程實例,而不是系統重新平衡所有內核或全部兄弟姐妹的過程。通過運行ps -eo pid,psr,comm檢查處理器親和力(或任何你喜歡的ps(1)命令;添加psr列)。

爲了解決這個問題,你可能想用一個明確的限制CPU親和力開始你的員工:

taskset -c 0,1 node worker 1 
taskset -c 2,3 node worker 2 
taskset -c 4,5 node worker 3 
taskset -c 6,7 node worker 4 

或許開始八,每HT兄弟之一,或八和限制每個人給自己設定CPU ,或者16個,每個核心有四個,每個兄弟只有兩個,等等(你可以可以堅持嘗試微觀管理,我建議儘量保持簡單。)詳細信息請參見taskset(1)聯機幫助頁。

+0

非常好的答案。應該被接受。 – Drasill

+0

謝謝@Drasill;我會順便注意到,更新的Linux內核版本似乎更加準備好在處理器之間遷移任務,從而使'taskset'調用的重要性不如以往。我會很高興地離開這個,因爲所有那些較舊的Linux安裝需要十年才能遷移或更新版本。 – sarnold

相關問題