关于云计算:K8S环境的Jenkin性能问题处理

在 K8S 环境通过 helm 部署了 Jenkins（namespace 为 helm-jenkins），用于日常 Java 我的项目构建：

kubernetes：1.15
jenkins：2.190.2
helm 版本：2.16.1

如果您想理解 helm 部署 Jenkins 的详情，请参考《》

在 Jenkins 工作密集时，Jenkins 页面响应迟缓，偶然有白屏状况产生（稍后主动回复），而且构建速度也显著变缓，查看具体的数据：

K8S 环境已装了 metrics-server，用命令 kubectl top pod –all-namespaces 能够看到 Jenkins 所占内存仅有 410 兆，如下图：

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

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

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

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

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

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

在察看内存参数的过程中，ID 为 f9ae211abe99 的容器忽然不见了，取而代之的是一个 ID 为 7f1f94d79e46 新容器，如下图所示：

11. 执行命令 kubectl get event -n helm-jenkins 查看该命名空间的所有事件，如下图红框所示，发现原来是探针不响应迫使 K8S 重启该 pod：

对以后零碎的诊断曾经实现，依据后面的信息能够揣测：JVM 内存太小，YGC 频繁，甚至会有 FGC 呈现，零碎响应过慢还可能导致 K8S 探针判断容器不衰弱，引发 docker 容器被删除后从新创立，接下来就调整 JVM 参数，验证揣测是否正确；

宿主机节点有 16G 物理内存，没有其余业务，因而打算划分 8G 内存给 Jenkins；
执行命令 kubectl edit deployment my-jenkins -n helm-jenkins，编辑 jenkins 的 deployment，找到 JAVA_OPTS 参数的地位，在上面减少 value，如下图红框所示：

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

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

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

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

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

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

关于云计算:K8S环境的Jenkin性能问题处理

环境信息

问题形容

调整参数

对于批改参数的办法