Java EE 常見性能問題解決手冊(3)

willing66

[color="#02368d"]Java EE 常見性能問題解決手冊(3)
引自：http://blog.chinaunix.net/u/10516/showart_1003389.html
總結下，你應該依據(jù)合理性和重要性按下面的步驟依次去執(zhí)行:

• 　　1. 重構程序，盡量減少擁有session范圍的變量所存儲的信息量
  
• 　　2. 鼓勵你的客戶在他們使用完后，明確的釋放會話
  
• 　　3. 縮短超時的時間，以便于讓你內(nèi)存盡快的得到回收
  
• 　　4. 增加你堆空間的大小

　　無論如何，不要讓程序范圍級的變量，靜態(tài)變量，長生命周期的類存儲對象，事實上，你需要在內(nèi)存模擬器中去分析泄漏。
　　異常的持久空間
　　容易誤解JVM為持久空間分配內(nèi)存的目的。堆僅僅存儲類的實例，但JVM在堆中創(chuàng)建類實例之前，它必須把字節(jié)流文件(.class文件)裝載到
程序內(nèi)存中。它利用內(nèi)存中的字節(jié)流在堆中創(chuàng)建類的實例。JVM利用程序的內(nèi)存來裝載字節(jié)流文件，這個內(nèi)存空間稱為持久空間。圖6顯示了持久空間和堆的關
系:它存在于JVM程序中，并不是堆的一部分。

　　Figure 6. The relationship between the permanent space and the heap
　　通常，你可能想讓你的持久空間足夠大以便于它能夠裝載你程序所有的類，因為很明顯，從文件系統(tǒng)中讀取類文件比從內(nèi)存中裝載代價高很多。JVM提供了一個參數(shù)讓你不的程序不卸載已經(jīng)裝載到持久空間中的類文件:
　　–noclassgc
　　這個參數(shù)選項告訴JVM不要跑到持久空間去執(zhí)行垃圾收集釋放其中已經(jīng)裝載的類文件。這個參數(shù)選項很聰明，但是會引起一個問題:當持久空間滿了以
后依然需要裝載新文件的時候JVM會怎么處理呢?我觀測到的資料說明:如果JVM檢測到持久空間還需要內(nèi)存，就會調(diào)用主垃圾收集程序。垃圾收集器清除堆，
但它并不會對持久空間進行任何操作，因此它的努力是白費的。于是JVM就再重新檢測持久空間，看它是否滿，然后再次執(zhí)行程序，一遍的一遍重復。
我第一次碰到這種問題的時候，用戶抱怨說程序性能很差勁，并且在運行了幾次后就出現(xiàn)了問題，可能是內(nèi)存溢出問題。在我調(diào)查了詳細的關于堆和程序內(nèi)存
利用的收集器的記錄后，我迅速發(fā)覺堆的狀態(tài)非常正常，但程序確發(fā)生了內(nèi)存溢出。這個用戶維持了數(shù)千的JSP頁面，在裝載到內(nèi)存前把他們都編譯成了字節(jié)流文
件放入持久空間。他的環(huán)境已經(jīng)造成了持久空間溢出，但是在堆中由于用了 -noclassgc
選項，于是JVM并不去釋放類文件來裝載新的類文件。于是就導致了內(nèi)存溢出錯誤，我把他的持久空間改為512M大小，并去掉了 -noclassgc
參數(shù)。
　　正像圖7顯示的，當持久空間變滿了的時候，就引發(fā)垃圾收集，清理了樂園和幸存者空間，但是并不釋放持久空間中的一點內(nèi)存。

　　Figure 7. Garbage collection behavior when the permanent space becomes full. Click on thumbnail to view full-sized image.
　　注意
　　當設置持久空間大小時候，一般考慮128M，除非你的程序有很多的類文件，這個時候，你就可以考慮使用256M大小。如果你想讓他能夠裝載所有
的類的時候，就會導致一個典型的結構錯誤。設置成512M就足夠了，它僅僅是暫時的時間的花費。把持久空間設置成512M大小就象給一個腳痛的人吃止痛
藥，雖然暫時緩解了痛，但是腳還是沒有好，依然需要醫(yī)生把痛治療好，否則只是把問題延遲了而已。
　　線程池
　　外界同WEB或程序服務器連接的主要方法就是向他們發(fā)送請求，這些請求被放置到程序的執(zhí)行次序隊列中。和內(nèi)存最大的沖突就是程序服務器所設置的
線程池的大小。線程池的大小就是程序可以同時處理的請求的數(shù)量。如果池太小，請求就需要在隊列中等待程序處理，如果太大，CPU就需要花費太多的時間在這
些眾多的線程之間來回的切換。
　　每個服務器都有一個SOCKET負責監(jiān)聽。程序把接受到的請求放到待執(zhí)行隊列中，然后將這個請求從隊列移動到線程中被程序處理。
　　圖8顯示了服務器的處理程序。

　　Figure 8. 服務器處理請求的次序結構
線程池太小
　　每當我碰到有人抱怨裝載速度的性能隨著裝載的數(shù)量的增加變的越來越糟糕的時候，我會首先檢查線程池。特別是，我在看到下面這些信息的時候:

• 　　1.線程池的使用
  
• 　　2.很多請求等待處理(在隊列中等待處理)

　　當一個線程池被待處理的請求裝滿的時候，響應的時間就變的極其糟糕，因為這些在隊列中等待處理的請求會消耗很多的額外時間。這個時候，CPU的
利用率會非常低，因為程序服務器沒有時間去指揮CPU工作。這個時候，我會按一定幅度增加調(diào)節(jié)池的大小，并在未處理請求的數(shù)量減少前一直監(jiān)視程序的吞吐
量，你需要一個合理甚至更好的負載量者，一個精確的負載量測試工具可以準確的幫你測試出結果。當你觀測吞吐量的時候，如果你發(fā)現(xiàn)吞吐量降低了，你就應該把
池的大小下調(diào)一個幅度，一直到找到讓它保持最大吞吐量的大小為止。
　　圖9顯示了連接池太小的情況

　　Figure 9. 所有的線程都被占用了，請求就只能在隊列中等待
　　每當我閱讀性能調(diào)整手冊的時候，最讓我頭疼的就是他們從來不告訴你特殊情況下線程池應該是多大。由于這些值非常依賴程序的行為，他們只告訴你大普通情況下正確的大小，但是他們給了你一個范圍內(nèi)的值，這對用戶很有利的。例如考慮下面2種情況::

• 　　1. 一個程序從內(nèi)存中讀出一個字符串，把它傳給JSP頁面，讓JSP頁面去顯示
  
• 　　2.
  另一個程序從數(shù)據(jù)庫中讀出1000個數(shù)值，為這些不規(guī)則的數(shù)值求平均。第一個程序?qū)φ埱蟮幕貞獣�很塊，大概僅需要不足0.25秒的時間，且不怎么占據(jù)
  CPU。第二個程序可能需要3秒去回應，同時會占據(jù)CPU。因此，為第一個程序配置的池大小是100就有點太小了，因為程序能夠同時處理200個;但為第
  二個程序配置的池是100，就有點太大了，因為CPU可能就能應付50個線程。

　　但是，很多程序并沒有在這種情況下動態(tài)的去調(diào)整的功能。多數(shù)情況下是做相同的事，但是應該為他們劃分范圍。因此，我建議你為一個CPU分配50
到75個左右的線程。對一些程序來說，這個數(shù)量可能太少，對另一個些來說可能太多，我剛開始為每個CPU分配50到75個線程，然后根據(jù)吞吐量和CPU的
性能，并做適當?shù)恼{(diào)整。
　　線程池太大
　　除了線程池數(shù)量太小之外的情況外，環(huán)境也可能把線程數(shù)量配置的過大。當這些環(huán)境中的負載量不斷增大的時候，CPU的使用率會持續(xù)無法降低，就沒有什么響應請求的時間了，因為CPU只顧的在眾多的線程之間來回的切換跳動，沒時間讓線程去做他們應該做的事了。
　　連接池過大的最主要的跡象就是CPU的使用率一直很高。有些時候，垃圾收集也可能導致CPU使用率很高，但是垃圾收集導致的CPU使用率很高和
池過大導致的使用率有一個主要的區(qū)別就是:垃圾收集引起的只是短時間的高使用率就象個釘子，而池過大導致的就是一直持續(xù)很高呈線性。
　　這個情況發(fā)生的時候，請求會被放在隊列中不被處理，但是不會始終如此，因為請求占用CPU的情況和程序占用的情況造成的后果不同。降低線程池的
大小可能會讓請求等待，但是讓請求等待總比為了處理請求而讓CPU忙不過來的好。讓CPU保持持續(xù)的高使用率，同時性能不降低，新請求到來的時候放入到隊
列中，這是最理想的程序�？紤]下面這個很類似的情況:很多高速公里有交通燈來保證車輛進入到擁擠的公里中。在我看來，這些交通燈根本沒用，道理很充分。比
如你來了，在交通燈后面的安全線上等待進入到高速公路上。如果所有的車輛都同時涌向公里，我們就動彈不得，但是只要減緩涌向高速公路車輛的速度，交通遲早
會暢通。事實上，很多的大城市都有這樣功能，但根本沒用，他們真正需要的是一些更多的小路(CPU)，涌向高速公路的速度真的降低了，那么交通會變的正常
起來。


本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/24475/showart_1111147.html