记录一次生产服务器CPU400%满负荷处理过程

步骤

top命令

31779进程 占 CPU 361% ，通过最后的COMMAND可以判断是java进程

通过jvm的 jsp -l命令 查询

• 31779进程 是 zipkin-server-2.10.2-exec.jar

通过jvm的jstat命令 查询

• 该 java 进程GC回收的情况

jstat -gcutil 31779 5000 20

新生代(eden区)、老年代和元空间 一直是满的

FGC( full gc ) 3790770次 !!!

查看日志

 tail -n 200 catalina_zipkin.out

日志部分信息

...
2019-08-28 11:15:57.678  INFO 31779 --- [           main] z.s.ZipkinServer                         : Started ZipkinServer in 6.867 seconds (JVM running for 8.596)
Exception in thread "Thread-2" java.lang.OutOfMemoryError: GC overhead limit exceeded
Exception in thread "SimplePauseDetectorThread_0" java.lang.OutOfMemoryError: GC overhead limit exceeded
Exception in thread "XNIO-1 I/O-4" java.lang.OutOfMemoryError: GC overhead limit exceeded
Exception in thread "XNIO-1 Accept" java.lang.OutOfMemoryError: GC overhead limit exceeded

发现 是 OutOfMemoryError 内存溢出OOM

查询服务器 cpu 监测日志 发现在几天前就已经发生异常，一直是 cpu 满负荷

说明和本次客户集中大量使用系统并无关系

猜测

(可能不是实际情况)

可能原因是 之前的压力测试 -> 消息中心报错->日志堆积

导致的发送到ZipkinServer应用的消息过载，堆内存无法正常回收，从而引发OOM

解决方法

1.关闭该进程

• 因为进程实际上已经卡死
• 此进程是监控进程，并不影响实际业务

kill -9 31779

2.重启zipkin-server-2.10.2-exec.jar应用即可

3.再次进行压力测试，测试ZipkinServer多大堆内存可以避免这种情况的发生，合理增大jar应用启动时jvm的参数

反思

• 服务器 cpu 长期90%以上，云服务器应该设置报警机制
• 如果链路追踪没有什么实际作用，可以剔除相关的功能和配置
  • 在项目中间阶段引入该组件，但是实际业务并没有非常复杂的链路调用
  • 引入的组件越多，系统复杂度越高，运维成本越高

总结

处理过程

1. 找出异常占用进程
2. 找出该进程对应的应用
3. 如果是java应用，查看该应用的GC情况
4. 查看输出的日志文件
5. 分析原因
6. 解决方法
7. 反思