前言
作为在线系统负责人或者是一个技术专家,你可能刚刚接手一个项目就需要处理紧急故障,或者被要求帮忙处理一些紧急的故障,这个时候的情景是:
(1)你可能对这个业务仅仅是听说过,而不怎么真正了解;
(2)你可能没有这个故障的详细信息,比如可能仅仅是有使用方反馈服务中断了10分钟;
(3)你对代码细节还没有仔细研究过。
这个时候该怎么解决问题呢?根据以前的经验,工程师们常常倾向于直接登上服务器检查代码,试图立刻修改问题。或者是把某些可能是问题的配置做修改,但并不是100%确认这就是问题的根本原因。但结果往往是在解决问题的同时引入了新的问题,或者是没有找到问题的根本原因,导致用户的再次投诉。
正文
处理和排除故障分为4个必须的步骤:
(1) 紧急处理
(2) 添加监控
(3) 使用JDK性能监控工具
(4) 分析源代码。从治标不治本,到治标又治本。
紧急处理
紧急处理,顾名思义,是检查和评度当前故障的影响范围,并尽快使服务先恢复起来。其中检查和评估当前故障的影响范围是非常重要的。
以微博系统举例,一般用户的投诉率为千分之1,如果有超过10起用户投诉,就可能是大面积故障。如果只是负责线上跟踪的QA人员反馈的问题,而没有用户投诉,则可以有较多的时间去处理。
对于紧急的大面积故障,首先想到的不应该是检查问题。而是需要立刻追查最近线上系统是否有更改,我们的经验是95%的故障都是在新代码上线后的12小时内发生的。此时应该立刻回滚新更改。另外5%的故障大部分是由于业务扩展导致的。互联网业有一个规律,线上系统每半年需要重构一次,否则无法对应业务量的增长。对于这种业务量增长造成的故障,通常可以通过重启服务来紧急处理。
因此,紧急处理的首选是立刻回滚新更改。
添加监控
紧急处理之后,服务已经恢复了,但是问题并没有找到。如果是新代码上线造成的故障,回滚之后,工程师会有各种手段,在测试环境追查问题。而针对系统容量不足造成的故障,需要特别添加监控作为追查问题的重要手段。因为互联网业务请求高峰和低谷差别非常明显,微博业务中的请求高峰往往出现在晚上10点左右,而且不是稳定的出现。要求工程师们每天悲催的坐在电脑前守到晚上10点,却不见得能发现问题,是非常低效的。监控一般用一个简单的脚本就可以搞定,比如http服务监控,Shell脚本代码如下:
MAX_LATENCY_TIME=5
curl -m $MAX_LATENCY_TIME "http://1.2.3.4:8011/...."
if [ $? -ne 0 ] ; then
sIp=`hostname`
errmsg="gexin install latency > "$MAX_LATENCY_TIME"s"
// 具体告警的处理
echo $errmsg
echo send success
fi
使用JDK性能监控工具
刚刚添加的监控开始报警了。登上服务器,该做些什么呢?一般需要做如下动作,
(1)首先要查看日志,看看有没有Exception。另外日志中常常有对接口调用,缓存使用的监控告警信息。
(2)看看目前gc的状况如何,使用JDK自带的工具就可以。jstat -gc -h 10 vmid 5000,每5秒打出一次。我遇到过两次线上故障,都是简单的通过jstat就找到了问题。一次是Permanent区分配过小,JVM内存溢出。另一次是发生了过多的Full GC,使得系统停止响应。内存造成的问题通过简单的重启服务就可以使得服务恢复,但重启之后往往很快又出现问题。这个期间你要监控gc,看看期间发生了什么事情。如果是old区增长的过快,就可能是内存泄露。这个时候,你需要看看到底是什么对象占用了你的内存。
(3)jmap -histo vmid > jmap.log,该命令会打出所有对象,包括占用的byte数和实例个数。分享一个线上jmap实例,
Jmap.log代码
num #instances #bytes class name
---------------------------------------------
1: 10540623 668712400 [B
2: 10532610 252782640 com.google.protobuf.ByteString
3: 4305941 234036872 [Ljava.lang.Object;
4: 1066822 170691520 cn.abc.data.protobuf.UserWrap$User
5: 3950998 158039920 java.util.TreeMap$Entry
6: 3950159 126405088 com.google.protobuf.UnknownFieldSet$Field
7: 780773 118677496 cn.abc.data.protobuf.StatusWrap$Status
8: 4305047 103321128 java.util.ArrayList
9: 4301379 103233096 java.util.Collections$UnmodifiableRandomAccessList
10: 3207948 102654336 java.util.HashMap$Entry
11: 2571737 82300280 [C
12: 2569460 82222720 java.lang.String
13: 3952892 63246272 java.lang.Integer
14: 1314438 63093024 java.util.TreeMap
15: 2533229 60797496 java.lang.Long
16: 1065093 51124464 cn.abc.data.protobuf.PostSourceWrap$PostSource
17: 1314430 42061760 java.util.Collections$UnmodifiableMap
18: 284198 40924512 cn.sina.api.data.protobuf.CommentWrap$Comment
19: 4273 34273568 [Ljava.util.HashMap$Entry;
20: 459983 33118776 cn.abc.data.protobuf.AbcMessageWrap$AbcMessage
21: 458776 22021248 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
22: 458776 22021248 java.util.concurrent.FutureTask$Sync
23: 1314416 21030656 com.google.protobuf.UnknownFieldSet
24: 459982 11039568 cn.sina.datapush.notifier.core.DispatcherBase$MessageProcessor
25: 458776 11010624 java.util.concurrent.Executors$RunnableAdapter
26: 458776 7340416 cn.abc.datapush.notifier.core.DispatcherBase$MessageProcessor$1
27: 40897 5909152 <constMethodKlass>
28: 40897 4917592 <methodKlass>
29: 3193 3748688 <constantPoolKlass>
30: 62093 3274344 <symbolKlass>
排名前几位的都是Byte,Char,String,Integer之类的,不要灰心,继续往下看,后面会出现一些有趣的对象。第22位发现了45万个FutureTask,很显然这是不正常的。应该是某线程响应过慢,造成待处理任务出现了堆积。查看代码,果然处理线程只有4条,大量的请求得不到响应。通过gc分析,每5秒钟会产生100M左右的对象得不到处理,所以JVM heap很快就被耗尽。将线程数改为36条,问题立刻得到了解决。
(4)检查目前cpu占用情况,top -H,然后按“1”,会看到当前进程中每个线程所占CPU的比例。注意观察前几名,然后jstack -l vmid > jstack.log打出线程堆栈,看看是什么线程占用了CPU。这里需要注意的是,top -H显示的线程id是十进制,而jstack打出的线程堆栈是16进制。看看那些最忙的thread是不是那些真正应该忙的thread,如果是一些“黑马”线程,则要考虑是否是代码有死循环或者是意外的问题。
分析源代码
分析源代码是最有技术含量的事情,也是比较耗时而且不见得有效果的事情。所以我把源码分析放到解决线上问题的最后一步,因为必须要做到“有的放矢”。带着问题去分析代码,会比较容易。通过20%代码的修改,就可以解决80%的性能问题。比如上面这个线上问题,肯定是线程处理慢造成的问题。需要针对线程的调用,同步异步等进行分析。
相关推荐
线上故障排查方法记录
Java线上故障排查方案(2).pdf
Java线上故障排查方案 结合实战,超详细Java线上故障排查方案总结,值得收藏
JAVA线上问题排查和工具 内容详细 结合实际工作 贴合实际
主要介绍了JAVA线上常见问题排查手段(小结),小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
JAVA 线上故障排查完整套路,从 CPU、磁盘、内存、网络、GC 一条龙!.docx
通过全局视角实时查看应用 load、内存、gc、线程的状态信息,并能在不修改应用代码的情况下,对业务问题进行诊断,包括查看方法调用的出入参、异常,监测方法执行耗时,类加载信息等,大大提升线上问题排查效率
线上问题的排查方法及工具手段,对开发或者运维排查线上问题有很大帮助及使用排查问题使用的工具介绍
线上故障排查全套路,总有一款适合你线上故障排查全套路,总有一款适合你来自:fredal的博客链接:https://fredal.xin/java-error-c
EoC双向网改造导致电视播放异常故障排查.pdf EoC头端无法管理故障排查.pdf EoC终端注册不上故障排查.pdf EoC终端配置下发不生效故障排查.pdf EoC网络PPPoE拨号上网故障排查.pdf EPON EPON网络监控业务不通...
802.1x与EAD故障排查 AM接口故障排查 ARP-DETECTION故障排查 BGP MPLS故障排查 BGP故障排查 BPDU Tunnel故障排查 DHCP Server故障排查 DVPN HUB-HUB DVPN HUB-SPOKE 2 DVPN HUB-SPOKE DVPN DVPN故障排查 E1POS...
大厂高手骆俊武出品的《漫谈线上问题排查》电子书
本人整理一些工作多年运维常见的22个故障排查和解决方法供大家参考,方便提升自己处理工作经验
主要介绍了JAVA线上常见问题排查手段汇总,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
日立电梯故障维修排查实例.doc
针对数控车床主轴3挡、4挡无响应、不启动的实际故障,顺序排查了主轴传动系统、电气控制系统、PLC程序和数控系统接口线路等,找到了故障的原因,并根据故障的具体形式给出了一种经济实用的维修方法。
线上问题排查常用命令,包含linux命令,jstat,jinfo,jps等命令
NULL 博文链接:https://ainn2006.iteye.com/blog/1549724
电脑硬件故障排查实例。。。。。。。。。。。。