Java應用Docker化部署GC變長的踩坑經歷

做者簡介

超哥，2008年畢業後進入IT行業，目前就任於餓了麼物流架構部，曾就任於聯想研究院的AR設備視覺團隊和阿里巴巴的業務中臺團隊。 工做內容涉及大數據計算平臺構建，計算視覺雲端應用，業務中間件研發以及業務領域模型抽象與實現等。 即時配送業務的高速增加，對系統的複雜度提出了更大的挑戰，同時也給咱們足夠多的場景去嘗試與征服。

開發同窗反饋應用docker化部署以後，gc時間比KVM部署時漲了好幾倍，最近正好手熱，上機器擼了一把。

問題定位

經過gc日誌收集工具，查看jvm的gc信息，平均單次ygc的時間很是不穩定，但基本上都在100ms以上。

從集羣裏隨機挑了幾臺機器看了一下gc log，每次gc的堆大小都比較正常，可是時間不太科學。

猜想是gc線程出了問題。jinfo查看了

服務的docker容器分配了8核16g的資源，上面拉出來的gc線程和併發標記線程數是38和10，顯然不科學(猜想拉的宿主機的核數)。

默認的gc線程和併發標記線程數計算公式以下：

經過與運維同窗溝通，瞭解到宿主機是56核，根據上面公式進行計算，對上了。

修改配置灰度驗證

從集羣中隨機挑選幾臺機器進行灰度，修改下jvm啓動參數，增長 -XX:ParallelGCThreads=8(8是容器核數），設置了ParallelGCThreads以後CMS的併發標記線程數會同步降低。

運行了一個晚上和一個白天，發現灰度機的ygc變的很是平穩，時間降到了 10ms左右，gc的log以下:

結論

由於容器不是物理隔離的，部署的java應用，務必要指定-XX:ParallelGCThreads=CPU_COUNT ，以防被YGC被坑了。

閱讀博客還不過癮？

歡迎你們掃二維碼加入交流羣，討論和博客有關的技術問題，還能夠和博主有更多互動

博客轉載、線下活動及合做等問題請郵件至 shadowfly_zyl@hotmail.com 進行溝通