文档章节

一次生产 CPU 100% 排查优化实践

crossoverJie
 crossoverJie
发布于 2018/12/17 08:44
字数 1580
阅读 4918
收藏 167

前言

到了年底果然都不太平,最近又收到了运维报警:表示有些服务器负载非常高,让我们定位问题。

还真是想什么来什么,前些天还故意把某些服务器的负载提高(没错,老板让我写个 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强如 Disruptor 也发生内存溢出?

没想到又来一出。

为了更加直观的查看线程的状态信息,我将快照信息上传到专门分析的平台上。

http://fastthread.io/

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

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

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

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

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

解决问题

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

假设现在有 7 个业务类型,那就等于是创建 2*7=14Disruptor 队列,同时每个队列有一个消费者,也就是总共有 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 的使用率不高。

于是在和之前同样的条件下将等待策略换为 BlockingWaitStrategy


和刚才的 CPU 对比会发现到后面使用率的会有明显的降低;同时 dump 线程后会发现大部分线程都处于 waiting 状态。

优化解决

看样子将等待策略换为 BlockingWaitStrategy 可以减缓 CPU 的使用,

但留意到官方对 YieldingWaitStrategy 的描述里谈道: 当消费线程(Event Handler threads)的数量小于 CPU 核心数时推荐使用该策略。

而现有的使用场景很明显消费线程数已经大大的超过了核心 CPU 数了,因为我的使用方式是一个 Disruptor 队列一个消费者,所以我将队列调整为只有 1 个再试试(策略依然是 YieldingWaitStrategy)。

跑了一分钟,发现 CPU 的使用率一直都比较平稳而且不高。

总结

所以排查到此可以有一个结论了,想要根本解决这个问题需要将我们现有的业务拆分;现在是一个应用里同时处理了 N 个业务,每个业务都会使用好几个 Disruptor 队列。

由于是在一台服务器上运行,所以 CPU 资源都是共享的,这就会导致 CPU 的使用率居高不下。

所以我们的调整方式如下:

  • 为了快速缓解这个问题,先将等待策略换为 BlockingWaitStrategy,可以有效降低 CPU 的使用率(业务上也还能接受)。
  • 第二步就需要将应用拆分(上文模拟的一个 Disruptor 队列),一个应用处理一种业务类型;然后分别单独部署,这样也可以互相隔离互不影响。

当然还有其他的一些优化,因为这也是一个老系统了,这次 dump 线程居然发现创建了 800+ 的线程。

创建线程池的方式也是核心线程数、最大线程数是一样的,导致一些空闲的线程也得不到回收;这样会有很多无意义的资源消耗。

所以也会结合业务将创建线程池的方式调整一下,将线程数降下来,尽量的物尽其用。

本文的演示代码已上传至 GitHub:

https://github.com/crossoverJie/JCSprout

你的点赞与分享是对我最大的支持

© 著作权归作者所有

共有 人打赏支持
crossoverJie
粉丝 628
博文 80
码字总数 151801
作品 0
江北
后端工程师
私信 提问
加载中

评论(14)

9
92年的java
http://www.jujingyun.com 北京网站建设
http://www.shjuntang.com 上海装潢
游萧白
厉害厉害
不能告诉你我的名字
不能告诉你我的名字
厉害了,开发运维呀
12叔
12叔
这个不是使用问题么。
crossoverJie
crossoverJie

引用来自“就像风”的评论

Thread.yield() 方法使当前线程从执行状态(运行状态)变为可执行态(就绪状态)。cpu会从众多的可执行态里选择,也就是说,当前也就是刚刚的那个线程还是有可能会被再次执行到的,并不是说一定会执行其他线程而该线程在下一次中不会执行到了。

CPU 高的原因是因为外部那个 while 循环吧。因为其它线程都未工作,所以一起被当前线程一直在被执行,而 wait 方法是直接让线程变成 WAIT 状态这个期间线程根本不工作,CPU自然会降低。就好像你写一个无限循环什么都不做 CPU 肯定要被跑死,这里的 yield 实际就是防止这种事情发生。
是的 自旋一直在执行 yield 让出CPU;所以换了一种策略可以有效降低。
就像风
就像风
Thread.yield() 方法使当前线程从执行状态(运行状态)变为可执行态(就绪状态)。cpu会从众多的可执行态里选择,也就是说,当前也就是刚刚的那个线程还是有可能会被再次执行到的,并不是说一定会执行其他线程而该线程在下一次中不会执行到了。

CPU 高的原因是因为外部那个 while 循环吧。因为其它线程都未工作,所以一起被当前线程一直在被执行,而 wait 方法是直接让线程变成 WAIT 状态这个期间线程根本不工作,CPU自然会降低。就好像你写一个无限循环什么都不做 CPU 肯定要被跑死,这里的 yield 实际就是防止这种事情发生。
岁月轻狂k
岁月轻狂k
厉害👍
h-anybbo
h-anybbo

引用来自“Doolk”的评论

对于CPU的使用率问题我一直有个把握不定的问题是:充分利用CPU资源 和 CPU资源被占用。 因为CPU 使用率高有时候也反映了机器资源得到了充分利用,不知道作者有啥见解。
某个进程把CPU占完会影响其他进程的效率
D
Doolk
对于CPU的使用率问题我一直有个把握不定的问题是:充分利用CPU资源 和 CPU资源被占用。 因为CPU 使用率高有时候也反映了机器资源得到了充分利用,不知道作者有啥见解。
CPU 100% 异常排查实践与总结

CPU 100% 异常排查实践与总结 leejun2005的个人页面2018-01-041 阅读 java 1、问题背景 昨天下午突然收到运维邮件报警,显示数据平台服务器cpu利用率达到了98.94%,而且最近一段时间一直持续...

leejun_2005的个人页面
2018/01/04
0
0
实战课堂:一则CPU 100%的故障分析处理知识和警示

案情描述: 11点20分,DBA接到CPU告警短信,业务数据库2节点CPU使用率达到100%; 11点22分,DBA登陆业务数据库进行核查,发现数据库两个节点CPU使用率达到100%,并且有library cache lock以及...

技术小能手
2018/05/21
0
0
PgSQL · 最佳实践 · CPU满问题处理

前言 在数据库运维当中,一个DBA比较常遇到又比较紧急的问题,就是突发的CPU满(CPU利用率达到100%),导致业务停滞。DBA不一定非常熟悉业务实现逻辑,也不能掌控来自应用的变更或负载变化情...

阿里云RDS-数据库内核组
2017/07/10
0
0
Java进程CPU使用率高排查

原文出处 DevOps学院:http://www.devopsedu.com/front/articleinfo/5 生产java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下。 1.jps 获取Java进程的PID。 2.js...

kuSorZ
2017/11/17
0
0
Java进程CPU使用率高排查

生产java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下。 1.jps 获取Java进程的PID。 2.jstack pid >> java.txt 导出CPU占用高进程的线程栈。 3.top -H -p PID 查...

baishuchao
2017/08/24
0
0

没有更多内容

加载失败,请刷新页面

加载更多

大数据教程(11.9)hive操作基础知识

上一篇博客分享了hive的简介和初体验,本节博主将继续分享一些hive的操作的基础知识。 DDL操作 (1)创建表 #建表语法CREATE [EXTERNAL] TABLE [IF NOT EXISTS] table_name [(col_name ...

em_aaron
今天
0
0
OSChina 周四乱弹 —— 我家猫真会后空翻

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @我没有抓狂 :#今天听这个# 我艇牛逼,百听不厌,太好听辣 分享 Led Zeppelin 的歌曲《Stairway To Heaven》 《Stairway To Heaven》- Led Z...

小小编辑
今天
1
0
node调用dll

先安装python2.7 安装node-gyp cnpm install node-gyp -g 新建一个Electron-vue项目(案例用Electron-vue) vue init simulatedgreg/electron-vue my-project 安装electron-rebuild cnpm ins......

Chason-洪
今天
3
0
scala学习(一)

学习Spark之前需要学习Scala。 参考学习的书籍:快学Scala

柠檬果过
今天
3
0
通俗易懂解释网络工程中的技术,如STP,HSRP等

导读 在面试时,比如被问到HSRP的主备切换时间时多久,STP几个状态的停留时间,自己知道有这些东西,但在工作中不会经常用到,就老是记不住,觉得可能还是自己基础不够牢固,知识掌握不够全面...

问题终结者
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部