《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！

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：

12. 诊断完成，根据前面的信息可以推测：JVM内存太小，YGC频繁，甚至会有FGC出现，系统响应过慢还可能导致K8S探针判断容器不健康，引发docker容器被删除后重新创建；

13. 基于上述结果制定的应对措施：调整JVM参数，减少GC；

调整参数

1. 宿主机节点有16G物理内存，没有其他业务，因此打算划分8G内存给Jenkins；

2. 执行命令kubectl edit deployment my-jenkins -n helm-jenkins，编辑jenkins的deployment，找到JAVA_OPTS参数的位置，在下面增加value，如下图红框所示：

3. 就像vi工具编辑文本文件那样操作，保存退出后，pod被重建；

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

5. 并发执行任务一段时间后，观察GC情况发现并不频繁：

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

7. 运行一段时间，确认任务可正常执行，页面操作也比较流畅，查看K8S事件，再也没有出现pod重启的事件；

关于修改参数的方法

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

至此，K8S环境下Jenkins性能问题处理已经完成，希望能给您带来一些参考；

最后

手绘了下图所示的kafka知识大纲流程图（xmind文件不能上传，导出图片展现），但都可提供源文件给每位爱学习的朋友

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
ava面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！**