本文主要是介绍记录一次CPU过高引起的服务不可用事件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
一.前言
二.程序日志定位
三.Mysql事务定位
四.程序代码定位
五.微服务注册异常定位
六.异常进程定位
6.1.进程的线程信息分析
6.2.进程的堆内存分析
七.总结
一.前言
系统收到客户大面积反馈,登系统反应慢,打不开,登录不上等问题,随即展开排查。
二.程序日志定位
通过程序日志定位,数据库连接池出现连接超时异常,排查对象转到mysql数据库。
三.Mysql事务定位
通过对mysql事务,锁的监控,发现大量事务挤压,随即排查程序代码中对事务的控制是否不合理。
四.程序代码定位
经过全局搜索代码中对事务提交和回滚的控制,没有疏漏点,并对个别逻辑进行缩小事务控制范围的的代码优化,对一些查询量较大和频繁的表增加索引,计划择时重启服务。
程序重启后,事务并没有消失,依然有挤压,随即对程序代码进行版本回退,排除近期新上线代码可能造成的影响。
五.微服务注册异常定位
在版本回退过程中,发现注册到nacos上的四个order服务,逐步”死掉”,直至order服务不可用。
并在order所在的服务器上发现,在order服务启动后,order服务CPU占用率逐步升高,程序日志无异常,进程存活。
通过分析,推断可能服务因为CPU资源占用问题向注册中心nacos心跳请求失败,注册中心把服务下线,排除掉代码中可能存在的死循环,线程阻塞的大方向后,随即对异常进程进行分析。
六.异常进程定位
6.1.进程的线程信息分析
- top命令列出当前服务器所有进程,并按cpu占用大小排序
- 根据第一步获取的进程号，查询进程里线程最占用cpu,使用命令：top -p 4001893 -H
- 把线程堆栈信息dump到本地存储，使用命令：jstack 4001893 > /home/app_oper/jstack.log
- 使用IBM的Thread and Monitor Dump Analyzer For Java工具对线程堆栈信息分析
在thread dump中，要留意下面几种状态
死锁，Deadlock（重点关注）
等待资源，Waiting on condition（重点关注）
• 等待获取监视器，Waiting on monitor entry（重点关注）
阻塞，Blocked（重点关注）
• 执行中，Runnable
• 暂停，Suspended
• 对象等待中，Object.wait() 或 TIMED_WAITING
• 停止，Parked
下面有详细的例子讲这种分析，大家参考原著
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
6.2.进程的堆内存分析
可能存在内存泄漏，GC频繁执行的情况
- 执行jmap -dump:format=b,file=/home/app_oper/heap.bin 4001893
- 使用IBM的HeapAnalyzer工具对生成的heap.bin进行分析
通过分析,发现对report_org_second_daily机构日报表的插入脚本过大。
定位到代码中,发现存在批量插入,数据量过大且组装成了单独的sql插入语句,并处在定时任务中,执行频率为5分钟。
对定时任务临时处理后重新部署上线,观察上述三种异常(事务,nacos,CPU)均未再出现。
七.总结
近期商城订单数量激增,定时任务在处理大数据量时出现性能问题,后续将对此类场景下可能存在的问题进行全面优化,排查线上问题,多使用相关工具,比如Java 命令行工具,可视化软件(HeapAnalyzer等),第三方插件(arthas,spring boot admin等),并做好日常系统巡检工作。
其他:
内存占用程序排序前10
ps aux --sort=-%mem | awk 'NR<=11{print $4,$11,$12,$13,$14,$15}'
磁盘占用文件排序前10
find . -type f -exec du -Sh {} + | sort -rh | head -n 11
参考:
springboot应用cpu飙升的原因排除_springboot cpu占用太高-CSDN博客
linux中java项目cpu高
MySQL执行状态查看与分析_查看mysql运行状态-CSDN博客
这篇关于记录一次CPU过高引起的服务不可用事件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
