最近这两天一直收到监控告警提示,告警周期都很短也就持续几分钟所以就忽略了。后面再次出现告警的时候总觉得不正常,于是开始排查原因。
从监控中可以看出cpu使用率一直在居高不下的状态,最高使用率达到93%。
简单分析下可能出问题的地方,分为5个方向:
- 系统本身代码问题
- 内部下游系统的问题导致的雪崩效应
- 上游系统调用量突增
- http请求第三方的问题
- 机器本身的问题
查看日志,没有发现什么明显的错误日志,初步排除代码逻辑处理错误。只发现有个job在处理zip压缩包?接下来继续分析
2019-03-26 18:06:22 |-INFO [pool-554-thread-8] in c.f.trip.abc.runable.ElongPriceRefresh - updateEnd! 2019-03-26 18:06:25 |-INFO [pool-554-thread-4] in c.f.trip.abc.runable.ElongPriceRefresh - updateEnd! 2019-03-26 18:06:26 |-INFO [pool-554-thread-3] in c.f.trip.abc.runable.ElongPriceRefresh - updateEnd! 2019-03-26 18:06:26 |-INFO [scheduler_Worker-5] in com.xxx.trip.abc.job.ElongRateUpdateJob - 总线程数:12; 2019-03-26 18:06:41 |-INFO [scheduler_Worker-5] in com.xxx.trip.abc.job.ElongRateUpdateJob - 总线程数:12; 2019-03-26 18:06:48 |-INFO [pool-554-thread-7] in c.f.trip.abc.runable.ElongPriceRefresh - updateEnd! 2019-03-26 18:06:56 |-INFO [scheduler_Worker-5] in com.xxx.trip.abc.job.ElongRateUpdateJob - 总线程数:11; 2019-03-26 18:07:00 |-INFO [scheduler_Worker-1] in com.xxx.trip.abc.job.AuditCancelJob - audit cancel job start... 2019-03-26 18:07:00 |-INFO [scheduler_Worker-7] in c.f.trip.abc.job.AirPortTransferSmsJob - start AirPortTransferSmsJob ... 2019-03-26 18:07:00 |-INFO [scheduler_Worker-7] in c.f.trip.abc.job.AirPortTransferSmsJob - end AirPortTransferSmsJob ... 2019-03-26 18:07:00 |-INFO [scheduler_Worker-3] in c.f.t.s.train.abc.impl.TrainOrderServiceImpl - tip orders is empty 2019-03-26 18:07:03 |-INFO [scheduler_Worker-1] in com.xxx.trip.abc.job.AuditCancelJob - audit cancel job end! 2019-03-26 18:07:11 |-INFO [scheduler_Worker-5] in com.xxx.trip.abc.job.ElongRateUpdateJob - 总线程数:11; 2019-03-26 18:07:20 |-INFO [pool-554-thread-9] in c.f.trip.abc.runable.ElongPriceRefresh - updateEnd! 2019-03-26 18:07:26 |-INFO [scheduler_Worker-5] in com.xxx.trip.abc.job.ElongRateUpdateJob - 总线程数:10; 2019-03-26 18:07:28 |-INFO [scheduler_Worker-9] in com.xxx.trip.abc.job.QiantaoMinpriceJob - try again count :2,url = http://www.xxxx.com:7001/CF100296__hotelPrice_-1183552046.zip
上top工具,好家伙进程PID28204 cpu飙到168,下一步就是定位java线程拿出jstatck来分析。
查看线程top -Hp 28204 ,这里一共跑了600个线程,找到下面几个最高的线程,28210,28775,29475,29473,29468
将线程id转换为16进制 printf “%x\n” 线程ID
使用jstatck查看线程堆栈信息
jstack命令打印线程堆栈信息,命令格式:jstack pid |grep -A 10 tid
难道是这个线程影响cpu上升的吗? 赶紧联系开发人员一起查看。
开发说这个流式读取写入缓冲区,文件大小500M,左右,读取会比较慢,40分钟左右读完。每次任务跑完一次至少一个半小时
既然开发这样说了我表示怀疑的态度去看了一下配置文件,这分明是10分钟跑一次啊。让开发给个合适的值,修改后重启服务
cpu现在使用时60%,在观察几天看看。