成爲Java GC專家(4) — Apache的MaxClients參數詳解及其在Tomcat執行F

這是「成爲Java GC專家系列文章」的第四篇。

在第一篇文章 成爲JavaGC專家Part I — 深刻淺出Java垃圾回收機制 中咱們學習了不一樣GC算法的執行過程，GC如何工做，新生代及老年代的基本概念，在JDK7中你應該瞭解的5種GC類型以及他們的性能如何。

在第二篇文章 成爲JavaGC專家Part II — 如何監控Java垃圾回收機制 中咱們學到了JVM究竟是如何執行垃圾回收，咱們如何監控GC，以及那些工具可使得監控過程更高效。

在第三篇文章 成爲Java GC專家系列Part III–如何優化Java垃圾回收機制中咱們經過實際的例子學到了一些能夠優化GC的參數。同時咱們講解了如何減小對象被轉移到老年代空間，如何縮短Full GC時間，以及如何設置GC類型及內存空間。

在第四篇文章中，咱們將闡述Apache中MaxClients 參數的重要性，以及他如何在GC發生時，顯著地影響整個系統的性能。我將提供幾個例子以方便你理解MaxClients 致使的問題。同時我還會說明如何根據系統的內存狀況，設置最佳的MaxClients參數值。

MaxClients對於系統的影響

NHN (譯者注：NHN是做者工做的公司)服務的執行環境中存在一組Throttle valve-type參數（譯者注：節流閥參數，用於控制系統負載）。這些參數對於系統來講十分重要。下面咱們看一下Apache的 MaxClients 參數在Full GC 發生時是如何影響系統的。

大部分開發人員都知道在因爲GC發生而致使的」中止世界現象(STW) 「（詳細請參見Understanding Java Garbage Collection）。尤爲是，NHN的Java開發人員常常會遇到因爲GC緣由致使的Tomcat報錯。因爲Java 虛擬機 (JVM)管理着內存，以Java爲基礎的程序沒法擺脫GC致使的STW現象。假如在某一個時間，當你正在操做你開發的應用時，GC開始執行。即便TTS錯誤沒有發生，你的服務也會給客戶展示未預期的503錯誤。

服務執行環境

因爲架構自己的特色，相比較而言縱向擴展，Web服務更適合橫向擴展（譯者注:增長服務器的數量，而不是提升件配置）。所以，整體來說，物理設備會根據性能要求被配置成1臺Apache+n臺Tomcat。可是本文假設咱們的環境是1臺Apache+一臺Tomcat同時安裝在一臺主機行，以下圖所示。

圖1：本文假射的服務執行環境

僅供參考，本文描述的參數基於Apache 2.2.21 (prefork MPM)，Tomcat 6.0.35，CentOS 4.72 (32-bit)，jdk 1.6.0_24。

系統可用內存2GB，垃圾收集器使用ParallelOldGC，AdaptiveSizePolicy採用默認的設置true，堆內存空間600M

STW 和HTTP 503

讓咱們假設訪問Apache的請求爲 200 req/s且有10個httpd進程在運行，另外咱們暫時不考慮每一個請求的響應時間。在這種前提下，咱們假設因爲full GC致使的暫停時間爲1秒。當Full GC發生的時候Tomcat會怎樣？

第一件進入你腦海的事情應該是Tomcat會由於full GC而中止響應任何請求。在這種狀況下，當Tomcat暫停相應請求時Apache會發生什麼？

當Tomcat暫停時，請求會以200 req/s的速度不斷的涌入Apache。通常來講，在Full GC發生以前，請求的響應能夠快速地被10個或更多的httpd進程處理掉。可是，由於Tomcat暫停了，httpd進程會被不停地建立以相應新進請求。直到超過httpd.conf 文件中定義 MaxClients 爲止。因爲默認值爲256，Apache不會在意請求以200 req/s的速度涌入。

這時，新建立的httpd線程將如何呢？

Httpd進程經過mod_jk 模塊所管理的空閒的AJP鏈接，將請求轉發給Tomcat。若是沒有空閒鏈接，他會申請建立新的鏈接。可是，由於Tomcat暫停了，建立新鏈接的請求會被拒絕。所以這些請求會被存儲在backlog隊列中，數量的多少取決於server.xml中關於AJP Connector的設置。一旦請求數量超過backlog隊列的空間限制。Apache就會返回拒絕鏈接錯誤。而且返回HTTP 503 錯誤給用戶。

在這種假設條件下，默認的backlog隊列空間是100，而請求到達速度是200 req/s。所以，full GC致使的一秒鐘的暫停會使得超過100個請求返回503錯誤。

這樣，當Full GC結束後，backlog隊列中存儲的內容會被Tomcat接受並在經過工做線程處理，線程的最大數量取決於MaxThreads的值（默認200）。

MaxClients 與backlog

在這種狀況下，設定哪一個參數能夠避免返回給用戶503錯誤呢？

首先，咱們應該知道backlog的值要夠大，以致於可以容納全部由於Full GC致使暫停期間涌入的請求。換句話說太應該不小於200。

那麼，這麼設置以後會不會產生新的問題呢？

讓咱們假設將backlog設置爲200後再重複一下上面的過程。獲得的結果比以前更加嚴重。系統內存使用量通常狀況下爲50%，可是，在發生Full GC時快速增長到100%，同時致使交換內存空間快速增長，更爲嚴重的是致使Full GC的暫停時間從1秒變成了4秒甚至更多，系統在此期間徹底宕機，不能響應任何請求。

在第一種狀況下，只有100或更多的請求返回503錯誤。可是，當咱們把backlog調整到200後，超過500個請求會掛起3秒甚至更多地時間沒法獲得應答

上面這個例子能夠很好的說明當你沒有徹底理解各個設置之間的內在關係時（例如，對於系統的影響），盲目修改系統會致使什麼後果。

那麼，爲何會產生這個現象呢？

問題的根源在於 MaxClients 參數的特性。

將MaxClients 設置爲一個很大的值自己沒有問題，但最重要的是在設定MaxClients 參數時，你要確保即便等同於MaxClients 數量的httpd進程被同時建立，內存使用量也不會超過80%。

系統的內存交換參數通常被設定爲60（默認）。所以，當內存使用量超過80%時，就會進行內存交換。

讓咱們再來看一下爲何這個特性會致使上面那個嚴重的問題。當請求以200 req/s的速度涌向Tomcat時，Tomcat因爲full GC暫停了。此時backlog被設置爲200。Apache大約建立100個httpd進程。在這種狀況下，一旦內存使用量超過80%，操做系統會激活交換內存區域，而且因爲系統認爲JVM的老年代中的對象在很長一段時間內未被使用，而將他們移動到交換區域。

最終的結果是，GC使用了內存交換空間，暫停時間劇增。所以httpd進程數進一步增長。從而致使上面描述的內存使用量達到100%的狀況。

這兩個場合的惟一區別就是backlog的值：100 vs.200。爲何只在200的狀況下發生？

二者不一樣的緣由在於建立的httpd進程的數量。當backlog設置爲100時而且Full GC發生時，會建立100個請求的鏈接並保存在backlog隊列中。其餘請求獲得拒絕鏈接錯誤信息併發揮503錯誤。所以，總的httpd 進程數量僅僅會略高於100。而當backlog被設置爲200時，200個請求會建立鏈接，所以。總的httpd進程數會多於200。這樣超過閥值，從而致使內存交換的發生。緊接着，不考慮內存使用量而的設定 MaxClients參數，Full GC致使httpd進程數量暴增，引起內存交換，下降系統性能。

MaxClients參數的計算公式

若是系統的內存使2GB，MaxClients 的值在任何狀況下都不該該超過內存的80%（1.6GB），以免因爲內存交換致使的性能降低。換句話說。1.6GB的內存應該共享和分配給Apache，Tomcat以及那些默認被安裝的代理程序。

讓咱們假設代理程序被默認安裝在系統，並佔用了200m內存，對於Tomcat堆內存的-Xmx 被設定爲 600m。所以根據top命令的結果，Tomcat會一直佔用725m（Perm Gen + Native Heap Area）。最終Apache可使用700m內存空間。以下所示。

圖2：測試系統的top截屏

如上所述，咱們將內存設爲700m後MaxClients 應該是多少呢？

這要取決於加載模塊的數量，對於NHN Web服務來講。Apache只是個簡單的代理轉發，每一個httpd線程4m內存（根據top命令的結果）足以（參見圖2）。所以。700m內存對應的 MaxClients應該是175。

總結

一個健壯的服務配置至少應該可以下降在服務過載時宕機的時間，在合理的範圍內成功的應答請求。針對基於Java的Web服務。你必須檢查你的服務在Full GC致使的STW時間內可否穩定的響應請求。

爲了響應更多的用戶請求和應對DDoS攻擊，在沒有全面考慮系統內存等因素的狀況下，貿然地將 MaxClients設置爲一個很大的值，那麼它將失去做爲閥值的功能，而致使系統出現更嚴重的問題。

本文提到的狀況只會持續3-5秒，所以絕大多數傳統的監控工具都沒法及時的發現。

做者 Dongsoon Choi 高級工程師@Game Service Technical Support Team, NHN Corporation.

英文原文：cubrid，編譯：ImportNew-王曉傑

譯文地址： http://www.importnew.com/3151.html