發布或重啟線上服務時抖動問題解決方案
轉自http://www.cnblogs.com/LBSer/p/3703967.html
一、問題描述
在發布或重啟某線上某服務時（jetty8作為服務器），常常發現有些機器的load會飆到非常高（高達70），並持續較長一段時間（5分鐘）後回落（圖1），與此同時響應時間曲線（圖2）也與load曲線一致。註：load飆高的初始時刻是應用服務端口打開，流量打入時（load具體指什麽可參考http://www.cnblogs.com/amsun/p/3155246.html）。
圖1 發布時候load飆高
圖2 發布時候響應時間飆高
二、問題排查方法
發布時對資源使用情況進行監控。
1）通過top -H -p 查找cpu使用率較高的線程，發現2129和2130這兩個線程cpu使用較高。
圖3 查找cpu使用率較高的線程
2）通過jstack打印棧信息，並將線程號2129和2130轉換成16進制（printf "%x\n" 2129），分別為851和852，發現這兩個線程是編譯線程（表1）。此外當這兩個線程cpu使用率降低後load以及響應時間也馬上恢復了正常，時間點非常吻合。
表1 cpu使用率較高的兩個線程詳細信息
| 1 2 3 4 5 6 7 8 |
"C2 CompilerThread1" daemon prio=10 tid=0x00007fce48125800 nid=0x852 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLELocked ownable synchronizers:
- None
"C2 CompilerThread0" daemon prio=10 tid=0x00007fce48123000 nid=0x851 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
|
三、現象解釋
C2 CompilerThread線程項目啟動初期cpu使用率那麽高，它在幹什麽呢？
Java程序在啟動的時候所有代碼的執行都處於解釋執行模式，只有在運行了一段時間後，根據代碼方法執行的次數，或代碼裏循環的執行次數等達到一定的閾值才會編譯成機器碼，編譯成機器碼後執行效率會得到大幅提升，而隨著執行時間進一步拉長，JVM的各種更高級的編譯優化手段就會逐漸加上，例如if條件的執行狀況，逃逸分析等。這裏的C2 CompilerThread線程幹的就是編譯優化的活。
現在貌似可以解釋之前的現象了。
在程序剛啟動的時候，java還處於解釋執行模式，因此服務效率很低，響應時間緩慢，處理得慢了，load自然也就高了。而當流量持續不斷導入時，我們代碼的很多方法執行次數不斷增多，此時C2 CompilerThread線程不斷收集優化信息，並且開始將一些熱點代碼優化編譯成本地機器碼，因此該線程的cpu使用率增高。而當C2 CompilerThread線程完成初始編譯優化過程後，C2 CompilerThread線程的cpu使用率開始下降，與此同時優化後服務的性能大幅提升，服務響應時間也大大縮短，load也下降。
現在的癥結在於編譯優化過程持續時間較長，引起抖動。如何降低編譯優化的持續時間呢？
四、解決思路
1）預熱
如果在服務接受線上請求之前提前完成編譯優化過程，那麽將能避免此種抖動情況。一般的做法是預熱，有兩種方法：
a）程序主動預熱：在啟動完成後，程序主動的訪問熱點的代碼，確保主要的熱點代碼已被編譯成機器碼後再放入流量，可通過-XX:+PrintCompilation來確認。
b）復制流量預熱：通過tcpcopy軟件拷貝一份線上nginx的流量進行預熱，完成之後再導入線上流量。
2）啟動多個線程進行編譯優化
如果能加快編譯優化速度，那也能降低解釋執行階段導致的抖動時間。因此可以多拿幾個線程來做編譯，加快達到高峰性能的速度。
可以使用-XX:CICompilerCount參數來設置編譯線程數目，這個值默認是2（之前在棧裏看到有兩個編譯線程），我們可以加到4。
3）采用多層編譯
編譯方式有三種：1）Client模式；2）Server模式；3）Tiered模式。我們服務默認是Server模式。
Server模式是采用c2高級編譯的，會比較耗時且要運行一段時間才會觸發編譯。 Server模式的優點是編譯後程序效率較高；
Client模式比較輕量也比較快觸發（比Server模式觸發快），編譯優化後程序效率不如Server模式；
Tiered模式是Client模式和Server模式的折中，一開始會啟用Client模式，可以在啟動後更快的讓部分代碼先進入編譯優化階段，之後會啟動Server模式，達到程序效率最大優化的目的。
Oracle JDK 7裏的HotSpot VM已經開始有比較好的Tiered編譯（tiered compilation）支持，可以設置參數-XX:+TieredCompilation來啟動Tiered模式，java 8默認就是Tiered模式。
圖4是到http://www.javaworld.com/article/2078635/enterprise-middleware/jvm-performance-optimization--part-2--compilers.html截取的不同編譯方式的性能比較圖，橫坐標是時間，縱坐標是性能。可以看出Tired模式開始階段性能與C1相當，當到達某一時刻後性能與C2相當。
圖4 不同編譯模式的性能比較
五、結果分析
簡單起見采用方案2和方案3來進行優化。
采用方案2和3之後進行了多次發布，發布時除個別機器load達到10之外，基本沒有過高現象（在2~4範圍內），並且短時間(2分鐘)內，load都會降到較合理水平（2左右），較發布時的load來看，比優化前要好很多。
方案2和方案3只是降低了抖動持續的時間以及抖動強度，並不能完全避免抖動。真正能避免抖動的方案應該是方案1，通過預熱的方式實現平滑發布或重啟。
發布或重啟線上服務時抖動問題解決方案