技術性問題 – 您需要多少個PHP/Python/Ruby 應用伺服器背景工作執行緒？

我們經常會碰到由於不知道如何配製應用伺服器線程而導致應用伺服器過載或崩潰的問題。儘管此類問題經常出現在PHP語言中，但是在其它語言中也會出現這些問題，它們所表現出來的都是同一類問題。

這些問題通常與隊列理論及低負載下動態多層隊列行為有關，也與輸送量及到達率和服務時間有關。這樣要進行合理的系統配置就變得更為困難，再加上預設設定比較差，而且繁忙系統也缺乏直覺。最後，多核CPU結構很難理解而且即時排除故障也很困難。

但是，若您仔細閱讀下文解釋，您會發現解決這一問題也很簡單。

首先，需要理解問題產生的原因，應用伺服器在高負載時要麼是CPU不夠，要麼是RAM不夠或者兩者都不夠，雖然RAM問題通常就是CPU問題。不管是RAM不夠還是CPU不夠，都是災難性的，因為它們會導致伺服器崩潰，而配置較差的伺服器情況會更糟。

導致該問題產生有兩個重要的因素。

第一個因素是：很多應用程式編寫得並不好，而且在CPU上啟動並執行很慢，通常要等1或數秒才開始執行。但是這種慢性執行速度通常在快速測試及程式開發伺服器或有強大硬體的上線系統上表現的並不明顯。但是，當系統在低載時，計算能力低下的情況下，若發生這種狀況，確實是一種災難。

第二個因素是：許多應用程式很消耗RAM，這主要是因為無用的大型的DB結果緩衝，或記憶體流失，導致佔用了很大的記憶體。每天我們都會發現機器中啟動並執行一些程式平均每個執行個體佔用記憶體達100-256MB， 最差的單個進程甚至可能使用500MB以上的記憶體。

以上例資料作參考，若一個16核的機器運行32個程式，僅僅應用程式，將至少佔用32x256MB或8GB RAM。甚至配置最好的伺服器，也會出現這樣的問題。由於程式佔用空間大，若RAM為4-8GB，情況會更糟。

若系統負載較大且延遲時間長的話，進程數目會增加。這是因為當Apache中的應用程式調度器等若發現所有進程都很忙的話，他將建立更多的進程，直到達到MaxClients（或FPM子進程數量）中設定 的極限值。通常有256子進程，乘以256MB， 將達到64GBRAM， 遠遠超過應用伺服器的RAM。

這一問題的直接後果就是，系統在進程數較少的時候，就開始交換，這將導致進程延遲及進程數量增加。 這種死迴圈的通常特點是：CPU過載，進程數量多，低RAM，swap使用過多，最終導致網站崩潰。 最壞的後果就是，由於swap使用過多，你甚至不能夠SSH登陸進系統去解決問題。

另一個導致系統失敗的原因就是，當有足夠的RAM的時候，CPU卻嚴重過載，然而系統卻在數百個Apache進程中頻繁交換。這將扼殺所有輸送量，更別提你想登陸進去。

最後，我們探索資料庫效能嚴重影響系統整體效能。不管應用伺服器是否繁忙，資料庫回應速度慢會使進程數量增多，導致伺服器RAM不足。

解決問題的方法很直截了當，就是將進程數量最大值設定為2倍核心數量。同時，要確保在達到最大記憶體使用量量時，你有足夠的RAM可以處理進程。這種情況下，CPU負載很大時，系統會變慢，但是，在這種配置下，會以合理的載入量，一直排在隊列中處理進程。

我們將其設為2倍核心數，是因為進程有延遲。例如，如果你要串連遠程DB，進程將在此連結過程中，處於暫停狀態，所以，在這段時間，你必須有額外的程式可以使CPU利用達到最大。

但是有個例外，就是當你有伺服器之外的RPC請求時，如查詢系統中的Lucense或Solr， 或真實的遠程系統如Facebook。 這些情況不在本部落格討論範圍內，但是它們採用了更複雜的配置及監控以確保系統高負載時仍能夠成功運行。

總結一下，將應用伺服器處理序設定為2xCores，並確保有足夠的RAM。這將使你的系統運行不會過載，且最佳化了你的系統，降低了CPU及RAM使用量，你可以在同樣的硬體上進行擴充。否則，你肯定會遇到系統擴充瓶頸。

（Authored by Steve Mushero / ChinaNetCloud CEO & CTO 本部落格英文原文請點此查看）