一份十分完整的CPU 100%排查优化指南

最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。

还真是想什么来什么，前些天还故意把某些服务器的负载提高(没错，老板让我写个 Bug!)，不过还好是不同的环境，互相没有影响。

定位问题

拿到问题后首先去服务器上看了看，发现运行的只有我们的 Java 应用。于是先用 PS 命令拿到了应用的 PID。

接着使用 top -Hp pid 将这个进程的线程显示出来。输入大写的 P 可以将线程按照 CPU 使用比例排序，于是得到以下结果：

果然某些线程的 CPU 使用率非常高。为了方便定位问题我立马使用 jstack pid > pid.log 将线程栈 Dump 到日志文件中。

我在上面 100% 的线程中随机选了一个 pid=194283 转换为 16 进制(2f6eb)后在线程快照中查询，因为线程快照中线程 ID 都是 16 进制存放。

发现这是 Disruptor 的一个堆栈，前段时间正好解决过一个由于 Disruptor 队列引起的一次 OOM，没想到又来一出。

为了更加直观的查看线程的状态信息，我将快照信息上传到专门分析的平台上：http://fastthread.io/

其中有一项菜单展示了所有消耗 CPU 的线程，我仔细看了下发现几乎都是和上面的堆栈一样。

也就是说都是 Disruptor 队列的堆栈，同时都在执行 java.lang.Thread.yield 函数。

众所周知 yield 函数会让当前线程让出 CPU 资源，再让其他线程来竞争。

根据刚才的线程快照发现处于 Runnable 状态并且都在执行 yield 函数的线程大概有 30 几个。

因此初步判断为大量线程执行 yield 函数之后互相竞争导致 CPU 使用率增高，而通过对堆栈发现是和使用 Disruptor 有关。

解决问题

而后我查看了代码，发现是根据每一个业务场景在内部都会使用 2 个 Disruptor 队列来解耦。

假设现在有 7 个业务类型，那就等于是创建 2*7=14 个 Disruptor 队列，同时每个队列有一个消费者，也就是总共有 14 个消费者(生产环境更多)。

同时发现配置的消费等待策略为 YieldingWaitStrategy 这种等待策略确实会执行 yield 来让出 CPU。

代码如下：

初步看来和这个等待策略有很大的关系。

本地模拟

为了验证，我在本地创建了 15 个 Disruptor 队列同时结合监控观察 CPU 的使用情况。

创建了 15 个 Disruptor 队列，同时每个队列都用线程池来往 Disruptor 队列里面发送 100W 条数据。

消费程序仅仅只是打印一下：

跑了一段时间发现 CPU 使用率确实很高：

同时 Dump 线程发现和生产的现象也是一致的：消费线程都处于 Runnable 状态，同时都在执行 yield。

通过查询 Disruptor 官方文档发现：

YieldingWaitStrategy 是一种充分压榨 CPU 的策略，使用自旋 + yield 的方式来提高性能。

当消费线程(Event Handler threads)的数量小于 CPU 核心数时推荐使用该策略。

同时查阅到其他的等待策略 BlockingWaitStrategy (也是默认的策略)，它使用的是锁的机制，对 CPU 的使用率不高。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!