JavaEE程式在Glassfish的效能調優分析

　　Java EE應用的效能問題對嚴肅的專案和產品來說是一個非常重要的問題。特別是企業級的應用，併發使用者多，資料傳輸量大，業務邏輯複雜，佔用系統資源多，因此效能問題在企業級應用變得至關重要，它和系統的穩定性有著直接的聯絡。更加重要的是，效能好的應用在完成相同任務的條件下，能夠佔用更少的資源，獲得更好的使用者體驗，換句話說，就是能夠節省費用和消耗，獲得更高的利潤。

　　要獲得更好的效能，就需要對原來的系統進行效能調優。對執行在Glassfish上的JavaEE應用，調優是一件相對複雜的事情。在調優以前必須要認識到：對JavaEE的系統，調優是多層次的。一個JavaEE的應用其實是整個系統中很少的一部分。開發人員所開發的JavaEE程式，無論是JSP還是EJB，都是執行在JavaEE應用伺服器(Glassfish)之上。而應用伺服器本身也是Java語言編寫的，需要執行在Java虛擬機器之上。Java虛擬機器也只不過是作業系統的一個應用而已，和其他的應用(如Apache)對於作業系統來說沒有本質的區別。而作業系統卻執行在一定的硬體環境中，包括CPU，記憶體，網路卡和硬碟等等。在這麼多的層次中，每一個層次的因素都會影響整個系統的效能。因此，對一個系統的調優，事實上需要同時對每個層次都要調優。JavaEE應用效能調優不僅僅和Glassfish有關，Java語言有關，還要和作業系統以及硬體都有關係，需要調優者有綜合的知識和技能。這些不同層面的方法需要綜合縱效，結合在一起靈活使用，才能快速有效的定位效能瓶頸。下面是一些具體的案例分析:

　　記憶體洩漏問題

　　某個JavaEE應用執行在8顆CPU的伺服器上。上線執行發現效能不穩定。效能隨著時間的增加而越來越慢。通過作業系統的工具(mpstat)，發現在系統很慢的時候，只有一顆CPU很忙，其他的CPU都很空閒。因此懷疑是Java虛擬機器經常進行記憶體回收，因為虛擬機器在記憶體回收的時候，有的回收演算法通常只能執行在一個CPU上。通過Java虛擬機器的工具“jstat”可以清楚的看到，Java虛擬機器進行記憶體回收的頻率非常高，幾乎每5秒中就有一次，每次回收的時間為2秒鐘。另外，通過“jstat”的輸出還發現每次回收釋放的記憶體非常有限，大多數物件都無法回收。這種現象很大程度上暗示著記憶體洩漏。使用Java虛擬機器的工具“jmap”來獲得當前的一個記憶體映象。發現有很多(超過10000)個的session物件。這是不正常的一個現象。一般來說，session對應於一個使用者的多次訪問，當使用者退出的時候，session就應該失效，物件應該被回收。當我們和這個系統的開發工程師瞭解有關session的設定，發現當他們部署應用的時候，竟然將session的timeout時間設定為50分鐘，並且沒有提供logout的介面。這樣的設定下，每個session的資料都會儲存50分鐘才會被回收。根據我們的建議，系統提供了logout的連結，並且告訴使用者如果退出應用，應該點選這個logout的連結;並且將session的timeout時間修改為5分鐘。通過幾天的測試，證明洩漏的問題得到解決。

　　資料庫連線池問題

　　某財務應用執行在JavaEE伺服器上，後臺連線Oracle資料庫。併發使用者數量超過100人左右的時候系統停止響應。通過作業系統層面的程式監控工具發現程式並沒有被殺死或掛起，而CPU使用率幾乎為零。那麼是什麼原因導致系統停止響應使用者請求呢?我們利用Java虛擬機器的工具(kill -3 pid)將當前的所有執行緒狀態DUMP出來，發現JavaEE伺服器的大部分處理執行緒都在等待資料庫連線池的連線，而那些已經獲得資料庫連線的執行緒卻處於阻塞狀態。資料庫管理員應要求檢查了資料庫的狀態，發現所有的連線的session都處於死鎖狀態。顯然，這是因為資料庫端出現了死鎖的操作，阻塞了那些有資料庫操作的請求，佔用了所有資料庫連線池中的連線。後續的請求如果還要從連線池中獲取連線，就會阻塞在連線池上。當解決資料庫死鎖的問題之後，效能問題迎刃而解。

　　大物件快取問題

　　電信應用執行在64位Java虛擬機器上，系統執行得很不穩定，系統經常停止響應。使用程式工具檢視，發現程式並沒有被殺死或掛起。利用Java虛擬機器的工具發現系統在長時間的進行記憶體回收，記憶體回收的時間長達15分鐘，整個系統在記憶體回收的時候就像掛起一樣。另外還觀察到系統使用了12G的記憶體(因為是64位虛擬機器所以突破了4G記憶體的限制)。從開發人員那裡瞭解到，這個應用為了提高效能，大量使用了物件快取，但是事與願違，在Java中使用過多的記憶體，雖然在正常執行的時候能夠獲得很好的效能，但是會大大增加記憶體回收的時間。特別是物件快取，本系統使用了8G的快取空間，共快取了6000多萬個物件，對這些物件的遍歷導致了長時間的記憶體回收。根據我們的建議，將快取空間減少到1G，並調整回收演算法(使用增量回收的演算法)，使得系統由於記憶體回收而造成的最大停頓時間減少到4秒，基本滿足使用者的需求。

　　外部命令問題

　　數字校園應用執行在4CPU的Solaris10伺服器上，中介軟體為JavaEE伺服器。系統在做大併發壓力測試的時候，請求響應時間比較慢，通過作業系統的工具(mpstat)發現CPU使用率比較高。並且系統佔用絕大多數的CPU資源而不是應用本身。這是個不正常的現象，通常情況下使用者應用的CPU佔用率應該佔主要地位，才能說明系統是正常工作。通過Solaris 10的Dtrace指令碼，我們檢視當前情況下哪些系統呼叫花費了最多的CPU資源，竟然發現最花費CPU的系統呼叫是“fork”。眾所周知，“fork”系統呼叫是用來產生新的程式，在Java虛擬機器中只有執行緒的概念，絕不會有程式的產生。這是個非常異常的現象。通過本系統的開發人員，我們找到了答案：每個使用者請求的處理都包含執行一個外部shell指令碼，來獲得系統的一些資訊。這是通過Java的“Runtime.getRuntime().exec”來完成的，但是這種方法在Java中非常消耗資源。Java虛擬機器執行這個命令的方式是：首先克隆一個和當前虛擬機器一樣的程式，再用這個新的程式去執行外部命令，最後再退出這個程式。如果頻繁執行這個操作，系統的消耗會很大，不僅在CPU，記憶體操作也很重。使用者根據建議去掉這個shell指令碼執行的語句，系統立刻回覆了正常。

　　檔案操作問題

　　內容管理(CMS)系統執行在JavaEE伺服器上，當系統長時間執行以後，效能非常差，使用者請求的延時比系統剛上線的時候要大很多，並且使用者的併發量很小，甚至是單個使用者也很慢。通過作業系統的工具觀察，一切都很正常，CPU利用率不高，IO也不是很大，記憶體很富餘，網路幾乎沒有壓力(因為併發使用者少)。先不考慮執行緒互鎖的問題，因為單個使用者效能也不好。通過Java虛擬機器觀察也沒有發現什麼問題(記憶體回收很少發生)。這使得我們不得不使用程式碼跟蹤器來全程跟蹤程式碼。我們採用了Netbeans的Profiler，跟蹤的結果非常意外，使用者請求的90%的時間在建立新檔案。從系統設計人員瞭解到，此係統使用了一個目錄用於儲存所有上傳和共享的檔案，檔案用其命名方式來唯一區別於其他檔案。我們檢視了那個檔案目錄，發現該目錄下已經擁有80萬個檔案了。這時候我們才定位到問題了：在同個目錄下放置太多的檔案，在建立新檔案的時候，系統的開銷是比較大的，例如為了防止重名，檔案系統會遍歷當前目錄下所有的檔名等等。根據我們的建議，將檔案分類儲存在不同的目錄下，效能有了大幅度的提高。

　　快取記憶體命中率問題

　　執行在JavaEE伺服器上的ERP系統，在CPU充分利用的情況下效能仍然不太好。從作業系統層面上觀察不到什麼大問題，而且ERP系統過於複雜，程式碼跟蹤比較困難。於是進行了CPU狀態的進一步檢查，發現CPU的TLB命中率不是很高，於是對Java虛擬機器的啟動引數進行了修改，強迫虛擬機器使用大尺寸的記憶體頁面，提高TLB的命中率。下面的引數是在Sun的HOTSPOT中調整大尺寸(4M)頁面的設定：

　　-XX:+AggressiveHeap

　　-XX:LargePageSizeInBytes=256m

　　通過調整，TLB命中明顯提高，效能也得到近40%的提升。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13270562/viewspace-242656/，如需轉載，請註明出處，否則將追究法律責任。