K8S環境的Jenkin性能問題處理

環境信息

在K8S環境經過helm部署了Jenkins（namespace爲helm-jenkins），用於平常Java項目構建：

1. kubernetes：1.15
2. jenkins：2.190.2
3. helm版本：2.16.1

若是您想了解helm部署Jenkins的詳情，請參考《》

問題描述

在Jenkins任務密集時，Jenkins頁面響應緩慢，偶爾有白屏狀況發生（稍後自動回覆），並且構建速度也明顯變緩，查看具體的數據：

1. K8S環境已裝了metrics-server，用命令kubectl top pod --all-namespaces能夠看到Jenkins所佔內存僅有410兆，以下圖：
   
2. Jenkins是Java應用，在處理大量任務的時候，410兆的內存應該是不夠的，JVM內存不足會致使頻繁的垃圾回收，接下來順着這個思路去看JVM內存狀況；
3. 由上圖可知pod名爲my-jenkins-74bcdfc566-lmhnw，經過kubectl describe pod my-jenkins-74bcdfc566-lmhnw -n helm-jenkins查看此pod詳情：
   
4. 由上圖紅框1可知此pod運行在node3節點，紅框2顯示對應的docker容器ID爲f9ae211abe99(前12位)；
5. 去node3機器上執行docker ps，果真發現了ID爲f9ae211abe99的容器，以下圖：
   
6. 執行命令docker exec f9ae211abe99 jps查看容器內全部java進程的PID，以下圖，可見Jenkins服務在容器內的PID等於6：
   
7. 知道了容器ID和java進程的PID，就能夠查看JVM信息了，執行命令docker exec f9ae211abe99 jstat -gcutil 6 3s 99查看GC狀況，以下圖，除了YGC頻繁，還出現了FGC：
   
8. 再用命令docker exec f9ae211abe99 jmap -heap 6查看JVM內存狀況，以下圖，年輕代過小了，只有100兆：
   
9. 最後用命令docker exec f9ae211abe99 ps -ef | grep java查看該進程的啓動命令，以下圖，可見啓動該java進程時並有指定內存參數：
   
10. 在觀察內存參數的過程當中，ID爲f9ae211abe99的容器忽然不見了，取而代之的是一個ID爲7f1f94d79e46新容器，以下圖所示：
    11. 執行命令kubectl get event -n helm-jenkins查看該命名空間的全部事件，以下圖紅框所示，發現原來是探針不響應迫使K8S重啓該pod：
    
    對當前系統的診斷已經完成，根據前面的信息能夠推測：JVM內存過小，YGC頻繁，甚至會有FGC出現，系統響應過慢還可能致使K8S探針判斷容器不健康，引起docker容器被刪除後從新建立，接下來就調整JVM參數，驗證推測是否正確；

調整參數

1. 宿主機節點有16G物理內存，沒有其餘業務，所以打算劃分8G內存給Jenkins；
2. 執行命令kubectl edit deployment my-jenkins -n helm-jenkins，編輯jenkins的deployment，找到JAVA_OPTS參數的位置，在下面增長value，以下圖紅框所示：
   
3. 找到docker容器ID後，執行命令docker exec 591dc47d4d57 jmap -heap 6查看JVM內存，以下圖所示，堆上限已經達到8G，年輕代是3686兆(調整前只有106兆)
   
4. 併發執行任務一段時間後，觀察GC狀況發現並不頻繁：
   
5. 再來看看該進程的啓動命令，執行命令docker exec 591dc47d4d57 ps -ef|grep java，以下圖紅框所示 ，剛纔設置的內存參數已經被用在啓動命令中了：
   
6. 運行一段時間，確認任務可正常執行，頁面操做也比較流暢，查看K8S事件，再也沒有出現pod重啓的事件；

關於修改參數的方法

除了kubectl edit命令，還能夠將helm的Jenkins配置信息所有下載到本地，修改配置後再部署Jenkins服務，若是您想了解更多，請參考《》

至此，K8S環境下Jenkins性能問題處理已經完成，但願能給您帶來一些參考；
https://github.com/zq2599/blog_demos