### 欢迎访问我的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/)

ITPub博客

K8S环境的Jenkin性能问题处理

最新文章