### 歡迎訪問我的GitHub
> 這裡分類和彙總了欣宸的全部原創(含配套原始碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos)

### 環境資訊
- 在K8S環境透過helm部署了Jenkins（namespace為helm-jenkins），用於日常Java專案構建：
1. kubernetes：1.15
2. jenkins：2.190.2
3. helm版本：2.16.1

- 如果您想了解helm部署Jenkins的詳情，請參考[《Helm部署和體驗jenkins》](https://blog.csdn.net/boling_cavalry/article/details/103670976)
### 問題描述
- 當Jenkins任務密集時，Jenkins頁面響應緩慢，偶爾有白屏情況發生（稍後自動恢復），且構建速度明顯變緩，此時去後臺看一下環境資訊：

- K8S環境已裝了metrics-server，用命令 **kubectl top pod --all-namespaces** 可以看到Jenkins所佔記憶體僅有410兆，如下圖：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321104756190.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- Jenkins是Java應用，在處理大量任務的時候，410兆的記憶體應該是不夠的，JVM記憶體不足會導致頻繁的垃圾回收，接下來順著這個思路去看JVM記憶體情況；
- 由上圖可知pod名為 **my-jenkins-74bcdfc566-lmhnw** ，透過 **kubectl describe pod my-jenkins-74bcdfc566-lmhnw -n helm-jenkins** 檢視此pod詳情：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321104916250.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 由上圖紅框1可知此pod執行在node3節點，紅框2顯示對應的docker容器ID為 **f9ae211abe99** (前12位)；
-  去node3機器上執行 **docker ps** ，果然發現了ID為 **f9ae211abe99** 的容器，如下圖：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105406270.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 執行命令 **docker exec f9ae211abe99 jps** 檢視容器內所有java程式的PID，如下圖，可見Jenkins服務在容器內的PID等於6：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105452669.png)
- 知道了容器ID和java程式的PID，就可以檢視JVM資訊了，執行命令 **docker exec f9ae211abe99 jstat -gcutil 6 3s 99** 檢視GC情況，如下圖，除了YGC頻繁，還出現了FGC：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/202003211055534.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 再用命令 **docker exec f9ae211abe99 jmap -heap 6** 檢視JVM記憶體情況，如下圖，年輕代太小了，只有100兆：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105738649.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 最後用命令 **docker exec f9ae211abe99 ps -ef | grep java** 檢視該程式的啟動命令，如下圖，可見啟動該java程式時沒有指定記憶體引數：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105811387.png)
- 在觀察的過程中，ID為 **f9ae211abe99** 的容器突然不見了，取而代之的是一個ID為 **7f1f94d79e46** 新容器，如下圖所示：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105906324.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 執行命令 **kubectl get event -n helm-jenkins** 檢視該名稱空間的所有事件，如下圖紅框所示，發現原來是探針不響應迫使K8S重啟該pod：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321105937353.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 診斷完成，根據前面的資訊可以推測：JVM記憶體太小，YGC頻繁，甚至會有FGC出現，系統響應過慢還可能導致K8S探針判斷容器不健康，引發docker容器被刪除後重新建立；
- 基於上述結果制定的應對措施：調整JVM引數，減少GC；
### 調整引數
- 宿主機節點有16G實體記憶體，沒有其他業務，因此打算劃分8G記憶體給Jenkins；
- 執行命令 **kubectl edit deployment my-jenkins -n helm-jenkins** ，編輯jenkins的deployment，找到JAVA_OPTS引數的位置，在下面增加value，如下圖紅框所示：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321110111648.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 就像vi工具編輯文字檔案那樣操作，儲存退出後，pod被重建；
- 找到docker容器ID後，執行命令 **docker exec 591dc47d4d57 jmap -heap 6** 檢視JVM記憶體，如下圖所示，堆上限已經達到8G，年輕代是3686兆(調整前只有106兆)：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2020032111014827.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 併發執行任務一段時間後，觀察GC情況發現並不頻繁：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321110205703.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvbGluZ19jYXZhbHJ5,size_16,color_FFFFFF,t_70)
- 再來看看該程式的啟動命令，執行命令 **docker exec 591dc47d4d57 ps -ef|grep java** ，如下圖紅框所示 ，剛才設定的記憶體引數已經被用在啟動命令中了：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20200321110227509.png)
- 執行一段時間，確認任務可正常執行，頁面操作也比較流暢，檢視K8S事件，再也沒有出現pod重啟的事件；
### 關於修改引數的方法
- 除了**kubectl edit**命令，還可以將helm的Jenkins配置資訊全部下載到本地，修改後再部署Jenkins服務，如果您想了解更多，請參考[《Helm部署的服務如何修改配置》](https://blog.csdn.net/boling_cavalry/article/details/105004586)

- 至此，K8S環境下Jenkins效能問題處理已經完成，希望能給您帶來一些參考；

### 歡迎關注ITpub：程式設計師欣宸
> [學習路上，你不孤單，欣宸原創一路相伴...](http://blog.itpub.net/70017844/)

K8S環境的Jenkin效能問題處理

相關文章