当前位置: 首页 > 网络应用技术

Java程序CPU使用率太高,无法调查和维修

时间:2023-03-07 11:31:56 网络应用技术

  我们的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