起因：收到GC STW報警
【監(jiān)控系統(tǒng)】Total time for which application threads were stopped: 67.7651070 seconds, Stopping threads took: 0.0000240 seconds
快速分析原因
此處不分析具體GC日志，主要分析方法:
從線上拷貝日志到本地
打包成gc.zip格式
上傳到gceasy.io
- image
找到原因
找到是因為缺IO或內(nèi)存資源導(dǎo)致高IO革娄，并不是GC本身過程耗時太多(上一步GC的報告中獲得)：
通過監(jiān)控系統(tǒng)翠忠，找到當(dāng)時機器IO飆升(公司內(nèi)部監(jiān)控機器的平臺蜈亩，zabbix實時收集機器的一些狀態(tài))：
深層次原因
整個應(yīng)用程序的停頓主要由兩部分組成：由于JVM GC行為造成的停頓(T1->T2)了嚎，以及為了記錄JVM GC日志(T3->T4)壤玫，系統(tǒng)調(diào)用write()被OS阻塞的時間精绎。下面這張圖展示了二者之間的關(guān)系祟霍。
解決方案
首先押搪，JVM實現(xiàn)完全可以解決掉這個問題。顯然浅碾，如果將寫GC日志的操作與可能會導(dǎo)致STW停頓的JVM GC處理過程分開大州，這個問題自然就不存在了。例如垂谢，JVM可以將記錄GC日志的功能放到另一個線程中厦画，獨立來處理日志文件的寫入，這樣就不會增加STW停頓的時間了滥朱。但是根暑，這種采用其他線程來處理的方式，可能會導(dǎo)致在JVM崩潰時丟失最后的GC日志信息徙邻。最好的方式排嫌，可能是提供一個JVM選項，讓用戶來選擇適合的方式,但這個方法基本沒辦法我們自己來處理缰犁。
由于后臺IO造成的STW停頓時間淳地，與IO的繁重程度有關(guān)怖糊，所以我們可以采用多種方式來降低后臺IO的壓力。例如颇象，不要在同一節(jié)點上安裝其他IO密集型的應(yīng)用程序伍伤，減少其他類型的日志行為，提高日志回滾頻率等等遣钳。
我們最后的解決辦法是將GC日志文件放到其他低IO磁盤上扰魂，把gc日志放到圖中的/data2,很明顯從iostat來看它的磁盤IO壓力很小。
