性能文章>性能测试连载 (42)-一次令人遗憾的 cpu 问题定位>

性能测试连载 (42)-一次令人遗憾的 cpu 问题定位原创

2月前
207426

概述

最近群里有一个小伙伴提了一个性能问题。大概描述是这样的。它的服务器cpu过载了。过载到什么程度呢?8个逻辑cpu一分钟内平均负载最高达到了529

平均负载解释

系统处于可运行状态和不可中断状态的平均进程数,平均活跃进程数。包括正在使用 CPU 的进程,还包括等待 CPU 和等待 I/O 的进程
可运行状态进程:正在使用 CPU 或者正在等待 CPU 的进程,处于 R 状态(Running 或 Runnable)的进程
不可中断状态的进程:正处于内核态关键流程中的进程,不可打断。比如等待IO

分析

从这位小伙伴提供的两张截图可以看出
1:八个逻辑cpu的利用率都是100%,而且70%左右的cpu时间消耗在了内核态(sy),几乎没有空闲


2:负载严重过高,估计有大量的进程堵在队列里面

针对负载过高的问题,我让他执行了一下vmstat 1 10
果然,运行队列有900多。。。而且疯狂上下文切换(cs严重超高)

更奇怪的是,在堵塞如此严重的情况下,还安排了其它进程来插队
如下图,一个监控的进程优先级远远的排在了阻塞进程的前面。等于是堵车已经堵的昏天黑地了,又有一辆车强行加塞挤到我的前面。

定位问题

既然已经明确是进程阻塞的问题,那么就可以通过dump的方式来找到问题的根源
执行 bash show-busy-java-threads观察堆栈结果。映入眼帘的全是runnable

这个已经很明显了,疯狂的日志写入导致了线程的堵塞。于是让这位小伙伴检查了一下日志输出。果然是日志全开

再观察其它的线程日志

这全是GC导致的线程阻塞了。可能是jvm内存不足,也可能是内存分配比例有问题

后记

其实到现在为止定位的都是用户空间的问题,还有很大一部分内核空间的问题没有定位到。但是遗憾的是,这位小伙伴似乎已经觉得问题都发现了,就再也没有搭理过我。。。
本来还想再让他看监听一下系统调用呢,实在是可惜了

总结一下

分析cpu问题先看负载,再看利用率,利用率分用户空间和内核空间。用户空间就去线程dump,内核空间就去监控系统调用。大致如下图

 

点赞收藏
飞天小子

13软件测试,10年性能测试,5年性能培训,10万字性能博主,惠普中国项目经理,微信uhz2008

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【全网首发】服务器被入侵了!

【全网首发】服务器被入侵了!

TPS分析优化案例
Mysql服务器CPU利用率过高分析

Mysql服务器CPU利用率过高分析

Mysql服务器线程阻塞分析

Mysql服务器线程阻塞分析

集群节点宕机问题排查

集群节点宕机问题排查

【全网首发】聊一聊 Tomcat 启动速度慢背后的真相

【全网首发】聊一聊 Tomcat 启动速度慢背后的真相

6
2