记一次线上故障排查过程(面试:有没有处理过线上CPU飙升,服务崩溃...问题)实操

172 阅读1分钟

背景

某晚,当小弟正在快乐亚索的时候,突然收到了两条紧急短信,提示所负责的线上应用出现Dubbo超时的情况;于是赶紧登录服务器查看此时的运行情况,看看是谁在搞我 wecom-temp-737a43088b7ef689647d464c6bf90d20.png

执行Linux top 命令 这里看出,PID为24020的Java应用 CPU已经飙到100%了 wecom-temp-b7a12815fe4e82c0cefd0164ec322094.png

处理过程

1. 执行命令执行 ps -mp 24020 -o THREAD,tid,time 查看此进行具体是哪个线程占用CPU最高

wecom-temp-4cba2d60c88a3dea95a01f7edf263aa8.png

2. 将线程号24061转为16进制 printf "%x\n" 24061

wecom-temp-d155edc04b4bd57213f3412c50698a8e.png

3.通过Jstack打印堆栈日志 jstack 24020 | grep 5dfd -A60
 通过这里的日志,我们可以定位到核心代码 com.qcloud.cos.http.IdleConnectionMonitorThread.run(IdleConnectionMonitorThread.java:44)这一块
(这个类包,我百度了一下是腾讯云 文件上传相关的东西)   

wecom-temp-26c29b72214f08a8fdaa11161a7f663e.png

wecom-temp-5a75ea7b4f5ae257d7beba527bea270c.png

4 找到代码里,哪里用到了腾讯文件上传相关的方法,并且查看自身系统是否有对应日志打印
  其实在这里就能看出原因了:
  某坑比调用此向腾讯云上传大文件,上传耗时花费了41204ms,接下来就是看这个方法是谁调用的,是谁在骚操作(这里就不赘述了).......

wecom-temp-0eef11df1bbb06aa0906d28139cbc5b8.png

wecom-temp-4b123025d5881a30debfe0ed4de843b0.png

总结

此次线上环境突发异常的罪魁祸首是 某坑壁 通过腾讯云api上传大文件,耗时41204ms,造成*****
后续规划 将文件传输的大小作出合理限制