linux服务器cup100%问题排查

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

第一次在查看的时候发现并没有我需要的服务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、控制台的日志可以不用打印，因为配置了指定的日志输出文件，而且控制台的日志有许多的冗余信息；
————————————————
版权声明：本文为CSDN博主「游荡程序洋」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lonyness/article/details/82628988