一、問題描述

在發(fā)布或重啟某線上服務(wù)時(shí)（jetty8作為服務(wù)器），常常發(fā)現(xiàn)有些機(jī)器的load會飆到非常高（高達(dá)70），并持續(xù)較長一段時(shí)間（5分鐘）后回落（圖1），與此同時(shí)響應(yīng)時(shí)間曲線（圖2）也與load曲線一致。注：load飆高的初始時(shí)刻是應(yīng)用服務(wù)端口打開，流量打入時(shí)（load具體指什么可參考https://blog.csdn.net/zl1zl2zl3/article/details/85059819）。

圖1 發(fā)布時(shí)候load飆高

?

圖2 發(fā)布時(shí)候響應(yīng)時(shí)間飆高

?

二、問題排查方法

發(fā)布時(shí)對資源使用情況進(jìn)行監(jiān)控。

1）通過top -H -p 查找cpu使用率較高的線程，發(fā)現(xiàn)2129和2130這兩個(gè)線程cpu使用較高。

圖3 查找cpu使用率較高的線程

?

2）通過jstack打印棧信息，并將線程號2129和2130轉(zhuǎn)換成16進(jìn)制（printf "%x\n" 2129），分別為851和852，發(fā)現(xiàn)這兩個(gè)線程是編譯線程（表1）。此外當(dāng)這兩個(gè)線程cpu使用率降低后load以及響應(yīng)時(shí)間也馬上恢復(fù)了正常，時(shí)間點(diǎn)非常吻合。

表1 cpu使用率較高的兩個(gè)線程詳細(xì)信息

"C2?CompilerThread1"?daemon?prio=10?tid=0x00007fce48125800?nid=0x852?waiting?on?condition? [0x0000000000000000]``java.lang.Thread.State:?RUNNABLE``Locked?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

?

三、現(xiàn)象解釋

C2 CompilerThread線程項(xiàng)目啟動(dòng)初期cpu使用率那么高，它在干什么呢？

Java程序在啟動(dòng)的時(shí)候所有代碼的執(zhí)行都處于解釋執(zhí)行模式，只有在運(yùn)行了一段時(shí)間后，根據(jù)代碼方法執(zhí)行的次數(shù)，或代碼里循環(huán)的執(zhí)行次數(shù)等達(dá)到一定的閾值才會編譯成機(jī)器碼，編譯成機(jī)器碼后執(zhí)行效率會得到大幅提升，而隨著執(zhí)行時(shí)間進(jìn)一步拉長，JVM的各種更高級的編譯優(yōu)化手段就會逐漸加上，例如if條件的執(zhí)行狀況，逃逸分析等。這里的C2 CompilerThread線程干的就是編譯優(yōu)化的活。

現(xiàn)在貌似可以解釋之前的現(xiàn)象了。

在程序剛啟動(dòng)的時(shí)候，java還處于解釋執(zhí)行模式，因此服務(wù)效率很低，響應(yīng)時(shí)間緩慢，處理得慢了，load自然也就高了。而當(dāng)流量持續(xù)不斷導(dǎo)入時(shí)，我們代碼的很多方法執(zhí)行次數(shù)不斷增多，此時(shí)C2 CompilerThread線程不斷收集優(yōu)化信息，并且開始將一些熱點(diǎn)代碼優(yōu)化編譯成本地機(jī)器碼，因此該線程的cpu使用率增高。而當(dāng)C2 CompilerThread線程完成初始編譯優(yōu)化過程后，C2 CompilerThread線程的cpu使用率開始下降，與此同時(shí)優(yōu)化后服務(wù)的性能大幅提升，服務(wù)響應(yīng)時(shí)間也大大縮短，load也下降。

?現(xiàn)在的癥結(jié)在于編譯優(yōu)化過程持續(xù)時(shí)間較長，引起抖動(dòng)。如何降低編譯優(yōu)化的持續(xù)時(shí)間呢？

?

四、解決思路

1）預(yù)熱

如果在服務(wù)接受線上請求之前提前完成編譯優(yōu)化過程，那么將能避免此種抖動(dòng)情況。一般的做法是預(yù)熱，有兩種方法：

a）程序主動(dòng)預(yù)熱：在啟動(dòng)完成后，程序主動(dòng)的訪問熱點(diǎn)的代碼，確保主要的熱點(diǎn)代碼已被編譯成機(jī)器碼后再放入流量，可通過-XX:+PrintCompilation來確認(rèn)。

b）復(fù)制流量預(yù)熱：通過tcpcopy軟件拷貝一份線上nginx的流量進(jìn)行預(yù)熱，完成之后再導(dǎo)入線上流量。

2）啟動(dòng)多個(gè)線程進(jìn)行編譯優(yōu)化

如果能加快編譯優(yōu)化速度，那也能降低解釋執(zhí)行階段導(dǎo)致的抖動(dòng)時(shí)間。因此可以多拿幾個(gè)線程來做編譯，加快達(dá)到高峰性能的速度。

可以使用-XX:CICompilerCount參數(shù)來設(shè)置編譯線程數(shù)目，這個(gè)值默認(rèn)是2（之前在棧里看到有兩個(gè)編譯線程），我們可以加到4。

3）采用多層編譯

編譯方式有三種：1）Client模式；2）Server模式；3）Tiered模式。我們服務(wù)默認(rèn)是Server模式。

Server模式是采用c2高級編譯的，會比較耗時(shí)且要運(yùn)行一段時(shí)間才會觸發(fā)編譯。 Server模式的優(yōu)點(diǎn)是編譯后程序效率較高；

Client模式比較輕量也比較快觸發(fā)（比Server模式觸發(fā)快），編譯優(yōu)化后程序效率不如Server模式；

Tiered模式是Client模式和Server模式的折中，一開始會啟用Client模式，可以在啟動(dòng)后更快的讓部分代碼先進(jìn)入編譯優(yōu)化階段，之后會啟動(dòng)Server模式，達(dá)到程序效率最大優(yōu)化的目的。

Oracle JDK 7里的HotSpot VM已經(jīng)開始有比較好的Tiered編譯（tiered compilation）支持，可以設(shè)置參數(shù)-XX:+TieredCompilation來啟動(dòng)Tiered模式，java 8默認(rèn)就是Tiered模式。

圖4是到 http://www.javaworld.com/article/2078635/enterprise-middleware/jvm-performance-optimization--part-2--compilers.html 截取的不同編譯方式的性能比較圖，橫坐標(biāo)是時(shí)間，縱坐標(biāo)是性能。可以看出Tired模式開始階段性能與C1相當(dāng)，當(dāng)?shù)竭_(dá)某一時(shí)刻后性能與C2相當(dāng)。

圖4 不同編譯模式的性能比較

?

五、結(jié)果分析

簡單起見采用方案2和方案3來進(jìn)行優(yōu)化。

采用方案2和3之后進(jìn)行了多次發(fā)布，發(fā)布時(shí)除個(gè)別機(jī)器load達(dá)到10之外，基本沒有過高現(xiàn)象（在2~4范圍內(nèi)），并且短時(shí)間(2分鐘)內(nèi)，load都會降到較合理水平（2左右），較發(fā)布時(shí)的load來看，比優(yōu)化前要好很多。

方案2和方案3只是降低了抖動(dòng)持續(xù)的時(shí)間以及抖動(dòng)強(qiáng)度，并不能完全避免抖動(dòng)。真正能避免抖動(dòng)的方案應(yīng)該是方案1，通過預(yù)熱的方式實(shí)現(xiàn)平滑發(fā)布或重啟。

總結(jié)

以上是生活随笔為你收集整理的涨姿势 | 服务重启后，为什么发生抖动？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。