一份异常完备的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 的行使率不高。

（编辑：湖南网）

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