我們經常會碰到由於不知道如何配製應用服務器線程而導致應用服務器過載或崩潰的問題。儘管此類問題經常出現在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 本博客英文原文請點此查看）
