技術性問題 – 您須要多少個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 本博客英文原文請點此查看）