关于云计算: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，用命令<font color=”blue”>kubectl top pod –all-namespaces</font>能够看到Jenkins所占内存仅有410兆，如下图：

1. Jenkins是Java利用，在解决大量工作的时候，410兆的内存应该是不够的，JVM内存不足会导致频繁的垃圾回收，接下来顺着这个思路去看JVM内存状况；
2. 由上图可知pod名为<font color=”blue”>my-jenkins-74bcdfc566-lmhnw</font>，通过<font color=”blue”>kubectl describe pod my-jenkins-74bcdfc566-lmhnw -n helm-jenkins</font>查看此pod详情：

1. 由上图红框1可知此pod运行在node3节点，红框2显示对应的docker容器ID为f9ae211abe99(前12位)；
2. 去node3机器上执行docker ps，果然发现了ID为f9ae211abe99的容器，如下图：

1. 执行命令docker exec f9ae211abe99 jps查看容器内所有java过程的PID，如下图，可见Jenkins服务在容器内的PID等于6：

1. 晓得了容器ID和java过程的PID，就能够查看JVM信息了，执行命令docker exec f9ae211abe99 jstat -gcutil 6 3s 99查看GC状况，如下图，除了YGC频繁，还呈现了FGC：

1. 再用命令docker exec f9ae211abe99 jmap -heap 6查看JVM内存状况，如下图，年老代太小了，只有100兆：

1. 最初用命令docker exec f9ae211abe99 ps -ef | grep java查看该过程的启动命令，如下图，可见启动该java过程时并有指定内存参数：

1. 在察看内存参数的过程中，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，如下图红框所示：

1. 找到docker容器ID后，执行命令docker exec 591dc47d4d57 jmap -heap 6查看JVM内存，如下图所示，堆下限曾经达到8G，年老代是3686兆(调整前只有106兆)

1. 并发执行工作一段时间后，察看GC状况发现并不频繁：

1. 再来看看该过程的启动命令，执行命令docker exec 591dc47d4d57 ps -ef|grep java，如下图红框所示 ，方才设置的内存参数曾经被用在启动命令中了：

1. 运行一段时间，确认工作可失常执行，页面操作也比拟晦涩，查看K8S事件，再也没有呈现pod重启的事件；

对于批改参数的办法

除了kubectl edit命令，还能够将helm的Jenkins配置信息全副下载到本地，批改配置后再部署Jenkins服务，如果您想理解更多，请参考《》

至此，K8S环境下Jenkins性能问题解决曾经实现，心愿能给您带来一些参考；
https://github.com/zq2599/blog_demos