环境信息

在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》

问题描述

当Jenkins任务密集时,Jenkins页面响应缓慢,偶尔有白屏情况发生(稍后自动恢复),且构建速度明显变缓,此时去后台看一下环境信息:

  • K8S环境已装了metrics-server,用命令kubectl top pod --all-namespaces可以看到Jenkins所占内存仅有410兆,如下图:
2d1cd47cbe5b9881d213ab44f7c4489f.png
  • Jenkins是Java应用,在处理大量任务的时候,410兆的内存应该是不够的,JVM内存不足会导致频繁的垃圾回收,接下来顺着这个思路去看JVM内存情况;
  • 由上图可知pod名为my-jenkins-74bcdfc566-lmhnw,通过由上图可知pod名为my-jenkins-74bcdfc566-lmhnw,通过kubectl describe pod my-jenkins-74bcdfc566-lmhnw -n helm-jenkins查看此pod详情:查看此pod详情:
993f0d309c00c2b85d0741ff2ebf0245.png
  • 由上图红框1可知此pod运行在node3节点,红框2显示对应的docker容器ID为f9ae211abe99(前12位);
  • 去node3机器上执行docker ps,果然发现了ID为f9ae211abe99的容器,如下图:
15915a778724426931bc8268ad511c5c.png
  • 执行命令docker exec f9ae211abe99 jps查看容器内所有java进程的PID,如下图,可见Jenkins服务在容器内的PID等于6:
327eb7f969c200d88194663a9822f5d1.png
  • 知道了容器ID和java进程的PID,就可以查看JVM信息了,执行命令docker exec f9ae211abe99 jstat -gcutil 6 3s 99查看GC情况,如下图,除了YGC频繁,还出现了FGC:
c329f14a53565226913493af5b50ca1a.png
  • 再用命令docker exec f9ae211abe99 jmap -heap 6查看JVM内存情况,如下图,年轻代太小了,只有100兆:
cb3f94e5211cfcd0c0023de8d7d32582.png
  • 最后用命令docker exec f9ae211abe99 ps -ef | grep java查看该进程的启动命令,如下图,可见启动该java进程时没有指定内存参数:
dd349185163976812a0b6a0c268cc781.png
  • 在观察的过程中,ID为f9ae211abe99的容器突然不见了,取而代之的是一个ID为7f1f94d79e46新容器,如下图所示:
4667d6f2aa03b54f8b88ea5a01a6d8b5.png
  • 执行命令kubectl get event -n helm-jenkins查看该命名空间的所有事件,如下图红框所示,发现原来是探针不响应迫使K8S重启该pod:
d4fadf8e8fbb9bd993dab28920fbe0de.png


诊断已经完成,根据前面的信息可以推测:JVM内存太小,YGC频繁,甚至会有FGC出现,系统响应过慢还可能导致K8S探针判断容器不健康,引发docker容器被删除后重新创建,接下来就调整JVM参数,验证推测是否正确;

调整参数

  • 宿主机节点有16G物理内存,没有其他业务,因此打算划分8G内存给Jenkins;
  • 执行命令kubectl edit deployment my-jenkins -n helm-jenkins,编辑jenkins的deployment,找到JAVA_OPTS参数的位置,在下面增加value,如下图红框所示:
eaedbe86e7d904ffeb8178393fe89962.png
  • 就像vi工具编辑文本文件那样操作,保存退出后,pod被重建
  • 找到docker容器ID后,执行命令docker exec 591dc47d4d57 jmap -heap 6查看JVM内存,如下图所示,堆上限已经达到8G,年轻代是3686兆(调整前只有106兆):
d21cf6fb0e0d9e9e30dd39088f19ba85.png
  • 并发执行任务一段时间后,观察GC情况发现并不频繁:
4025eda5a4b214ace085c9f7fb37341a.png
  • 再来看看该进程的启动命令,执行命令docker exec 591dc47d4d57 ps -ef|grep java,如下图红框所示 ,刚才设置的内存参数已经被用在启动命令中了:
66648b1b6cbf10cb531f04562217ff78.png
  • 运行一段时间,确认任务可正常执行,页面操作也比较流畅,查看K8S事件,再也没有出现pod重启的事件;

关于修改参数的方法

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

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

欢迎关注公众号:程序员欣宸

7f1974e22535e06f05bcba438f1af2d9.png
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐