解决主要交易应用中的CPU峰值问题

在本文中，我们将讨论如何解决在北美主要交易应用程序中出现的CPU高峰问题。 突然，此应用程序的CPU开始飙升至100％。

实际上，这个团队并没有进行任何新的代码部署，也没有进行任何环境更改，也没有翻转任何标志设置-但是突然之间，CPU开始出现故障。

我们甚至验证了流量是否有所增加，这归因于流量的激增。 但是流量也没有增加。

还请参见： C通过Java并成为第一的编程语言

数据采集

该应用程序在Java，Tomcat技术堆栈上运行。 我们要求站点可靠性工程（SRE）团队从发生此问题的机器上捕获以下两个工件：

1. top -H输出
2.线程转储

让我们看看这些工件在本节中包含什么。

1. top -H

总是由于线程导致CPU峰值。 因此，我们必须隔离导致此CPU峰值的线程。 显然，该应用程序具有数百个线程。 从这数百个线程中，我们需要确定导致CPU消耗激增的线程？ 这是第一个挑战。

这是“ top” unix命令行实用程序工具派上用场的地方。 你们大多数人可能都熟悉“ top” unix命令行实用程序。 此工具显示设备上正在运行的所有进程。 它还显示CPU，每个进程消耗的内存。

该工具有一个秘密的“ -H”选项，许多工程师对此并不熟悉。 可以这样调用：

$ top -H -p <PID>

PID是您的应用程序的流程ID。 显然，此应用程序的进程ID为31294。因此SRE团队发出了此命令。

$ top -H -p 31294

当使用“ -H”选项调用“ top”工具时，它将开始显示该特定进程中正在运行的所有线程。 它还将显示该进程中每个线程消耗的CPU和内存量。 以下是我们从该交易应用程序获得的输出：

从“ top -H”输出中可以看到，第一行中有一个ID为“ 11956”的线程。 仅此线程就消耗60.9％的CPU。 答对了！！ 这是第一个胜利。 现在，使用此“ top -H”选项，我们已经确定了正在消耗大量CPU的线程。

线程转储

我们的下一个挑战是识别此“ 11956”线程正在执行的代码行。 这是线程转储很方便的地方。 线程转储显示了应用程序中正在运行的所有线程及其代码执行路径（即堆栈跟踪）。

该博客重点介绍了捕获线程转储的8个不同选项。 您可以使用方便的选项。 我们使用了JDK中的“ jstack”工具来捕获线程转储。

Best Practise: Capture at least 3 thread dumps,in a gap of 10 seconds between each thread dump.

分析数据

现在，我们将“ top -H”输出和“线程转储”都上传到fastThread工具。 如果您不确定如何将“ top -H”输出和线程转储上载到fastThread工具， 请按照以下说明进行操作 。

该工具具有分析线程转储和“ top -H”输出并生成直观报告的功能。 这个工具分析并生成了这个漂亮的报告 。

此报告包含“ CPU | 内存”部分。 该部分将工具与top -H输出和线程转储结合起来，并提供应用程序中每个线程消耗的CPU和内存。

在上面的屏幕截图中，我们可以看到第一行的“ WebContainer：18”线程报告正在消耗“ 60.9％” CPU。

在最后一列上，您可以看到此线程的代码执行路径（即堆栈跟踪）。 您可以看到该工具现在报告线程名称（即'WebContainer：18'）和它正在执行的代码路径（当我们看到原始top -H输出时不可用）。

还请参见： Leyden项目，将静态图像引入Java平台和JDK

解析度

您会注意到“ WebContainer：18”线程正在执行java.util.WeakHashMap＃put（）行代码。 对于不了解的人，HashMap不是线程安全的实现。 当多个线程同时调用HashMap的get（）和put（）方法时，可能会导致无限循环。

当线程无限循环时，CPU消耗将开始飙升。 这就是此应用程序中发生的确切问题。 将WeakHashMap替换为ConcurrentHashMap后，问题已解决。

我们希望您发现此简单技术有用。

翻译自: https://jaxenter.com/troubleshooting-cpu-spike-171840.html