我们的Jenkins系统不时，CPU负载太高。
CPU负载太高后，SRE同学将收到通话警报。
在我们的监视系统中，我们可以看到，有时，CPU的负载确实很高，如下所示：
Jenkins系统本身是一个Java程序，它响应Java程序引起的过度CPU使用问题。GitHub上有一个现成的解决方案：show-busy-java-threads。
下载链接如下：
登录到机器。当CPU使用率很高时，执行show-busy-java-threads脚本：。
一些输出的选择如下：
从上面的输出可以看出，25.0％的CPU资源正在处理此请求。
根据此IP的说法，操作和维护同学定位为启动某个同学A的主动性A。同学正在执行一些计时任务，并定期提取作业结果。
问题在于，当我直接访问此界面：/job/jenkins-test-job/api/json时，返回并不慢，几乎可以很快返回。问题不应该是此接口的问题。
然后，我们从输出中看不起：查看问题的呼叫堆栈：
看起来此SAM验证用户权限太高，然后查看上面的代码。这是JSON的派生。
一般而言，将JSON的序列化和衍生化化与CPU进行了比较。更糟糕的是，此处使用的JSON序列化框架是Net.sf.json，而不是Java通常使用的Jackson和Gson。
直觉告诉我，这一定是该网络引起的过度CPU使用的问题。
评论：
通过以前维持詹金斯的学生，他们使用SAM Permissions改写了基于角色策略插件的Jenkins权限验证逻辑。在SAM Permissions的代码上，使用Net.sf.json作为非常有用JSON衍生物。
在这一点上，它是由net.sf.json回流的SAM永久插件的原因引起的问题。
为了验证此问题，我们获取SAM Permissions插件的代码-in。查找问题的关键代码：
可以看出，此代码将根据用户邮箱发送HTTP请求以调用SAM系统，获取用户的权限数据，然后将数据数据列为JSONOBJECT，即：
在当地，通过同学A的要求，我发现此请求确实较慢，并且CPU成本。通过调试来了解用户返回的JSON数据约为1M，而JSON Counter将CPU已满。
通过其他用户请求，发现处理很快，并且返回的JSON数据相对较小。
在这一点上，确认它是Net.SF.JSON框架的反序绩效问题，并且CPU使用率太高。我们需要用其他高性能JSON JSON序列化框架替换它。
替代方案是：Gson，Jackson，Fastjson等。
在选择之前，首先测试Gson和Jackson的性能，并与Net.sf.json进行比较。
JSON框架的性能测试，我们选择JMH框架。
JMH框架是JDK提供的官方性能基准测试套件。参考：https：//github.com/openjdk/jmh
代码显示如下：
测试的结果如下：
可以看出，格森和杰克逊彼此近乎近距离。
用GSON替换上一个代码，该代码如下：
重新计算权限插件后，再次检查CPU负载监控，并发现CPU负载确实下降了（05/13在下午左右在线）。
再次重新计算，问题已经解决。
这个问题花费了很多时间之前和之后，这也使DevOps团队很长一段时间困扰。大家工作后，它终于解决了问题。
本文也是以前的调查和解决方案的摘要。在同一时间，我还提醒所有人，当使用第三款罐装包装时，您必须注意罐子包裹是否有问题和安全问题。如果您不是当然，您可以使用JMH和其他手段来测试以下内容。
我是Mei Xiaoxi。最近，我在东南亚E -Commerce Company进行了DevOps。从本期开始，将共享Jenkins的CI/CD工作流程，其中包括K8S上的Jenkins。
如果您对Java或Jenkins感兴趣，欢迎与我联系，微信：WXWeven（备注DevOps），公共帐户：
本文由博客的多个平台OpenWrite发表！
原始：https：//juejin.cn/post/7099837901503987748