ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

记一次线上服务cpu占用率超过100%的问题排查

2021-08-04 17:03:03  阅读:189  来源: 互联网

标签:100% 打印 cpu 线程 进程 日志 占用率 id


关联文章:9种 OOM 常见原因及解决方案

一、出现问题

在发现公司门禁服务无法开门的第一时间,去线上服务器上查看了一下进程的运行情况,具体运行如下:

第一次在查看的时候发现并没有我需要的服务entranceguard进程(图片是后续截图的)

二、第一时间启动服务

在察觉到服务挂了之后,第一时间就是让服务重新启动,所以运行了项目下的python脚本,具体运行如下: 

此时再次使用ps -ef | grep java 命令时发现服务已经正常运行了,解决了第一紧急事情,然后接下来是对这次事件进行排查:

三、排查问题:

在排查问题的第一时间,通过top命令查看了当时的服务器的cpu与及内存及负载均衡的相关情况,发现我的进程占用cpu 100%而且整个负载超过1.0,所以此时发现运行有问题; 

此处找出占用cpu过高的java进程id:761,然后对该进程的每个线程的运行情况;

四、查看占用cpu过高的进程中所有线程的运行情况:

使用ps -mp pid -o THREAD,tid,time命令查看该进程的线程情况,发现该进程有一个线程占用率很高,具体如下: 


此处发现线程pid:795 占用cpu99.7%,基本问题线程已确定,然后定位线程的具体问题:

五:定位线程具体问题:

查看该线程的堆栈情况,先将线程id转为16进制,使用printf “%x\n” tid命令进行转换,因为线程堆栈情况记录的是线程的16进制id: 


然后根据该id通过命令 jstack pid |grep tid -A 30(pid:进程id,tid:线程id) 查出具体问题如下:

 è¿éåå¾çæè¿°

 
此时发现log4j打印dubbo日志的线程已阻塞,发现是线程无法写入,基本定位问题可能是磁盘空间的问题;

六、查看磁盘空间大小:

通过命令 df -h查询发现/dev/vda1该文件夹使用率100%,磁盘空间爆满 

è¿éåå¾çæè¿°
接下来通过命令du -sh *查看具体文件夹占用内存情况发现我的项目tomcat占用了90多G, 

 è¿éåå¾çæè¿°

è¿éåå¾çæè¿°

最后定位问题是在tomcat中的catalina.out控制台日志输出过大,造成磁盘空间占满,然后系统无法继续写日志,从而导致刚好dubbo服务打印的日志一直处于死锁状态,该线程陷入死循环,大量消耗cpu,最终的结果是内存溢出,杀死进程了;

七、解决问题:

① 删除掉了catalina.out文件,top指数直接下降:

è¿éåå¾çæè¿°

整个服务运行正常; 

②修改代码: 
将控制台打印的日志给禁用掉,并限制打印日志的大小,因为我的日志里面有打印base64位的图片日志,该日志所需空间太大,所以对日志禁用及限制;

八、本次感悟:

1、打印日志的时候不要过多,但是要清晰,就是核心问题体现出来; 
2、控制台的日志可以不用打印,因为配置了指定的日志输出文件,而且控制台的日志有许多的冗余信息;

标签:100%,打印,cpu,线程,进程,日志,占用率,id
来源: https://blog.csdn.net/ChaoticNg/article/details/119387952

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有