重启大法好!线上常见问题排查手册x
重启大法好!线上常见问题排查手册 一 线上常见问题定位 常见问题 1 :CPU 利用率高 CPU 使用率是衡量系统繁忙程度的重要指标,一般情况下单纯的 CPU 高并没有问题,它代表系统正在不断的处理我们的任务,但是如果 CPU 过高,导致任务处理不过来,从而引起 load 高,这个是非常危险需要关注的。
CPU 使用率的安全值没有一个标准值,取决于你的系统是计算密集型还是 IO 密集型,一般计算密集型应用 CPU 使用率偏高 load 偏低,IO 密集型相反。
问题原因及定位:
1 频繁 频繁 FullGC/YongGC 查看 gc 日志 • jstat -gcutil pid 查看内存使用和 gc 情况 2 代码消耗,如死循环,md5 等内存态操作 等内存态操作 1)arthas (已开源:https://github.com/alibaba/arthas)
• thread -n 5
查看 CPU 使用率最高的前 5 个线程(包含堆栈,第二部分有详解)
2)jstack 查找 ps -ef | grep java
找到 Java 进程 id top -Hp pid
找到使用 CPU 最高的线程 printf ‘0x%x’
tid
线程 id 转化 16 进制 • jstack pid | grep tid
找到线程堆栈
ps:输入“1”可查看每个 CPU 的情况,之前有团队遇到单个 CPU 被中间件绑定导致 CPU 飚高的 case。
常见问题 2 :load 高 load 指单位时间内活跃进程数,包含运行态(runnable 和 running)和不可中断态( IO、内核态锁)。关键字是运行态和不可中断态,运行态可以联想到 Java 线程的 6 种状态,如下,线程 new 之后处于 NEW 状态,执行 start 进入 runnable 等待 CPU 调度,因此如果 CPU 很忙会导致 runnable 进程数增加;不可中断态主要包含网络 IO、磁盘 IO 以及内核态的锁,如 synchronized 等。
问题原因及定位:
1 CPU 利用率高,可运行态进程数多 利用率高,可运行态进程数多 • 排查方法见常见问题一 2 iowait,等待 ,等待 IO vmstat 查看 blocked 进程状况 • jstack -l pid | grep BLOCKED
查看阻塞态线程堆栈 3 等待内核态锁,如 等待内核态锁,如 synchronized jstack -l pid | grep BLOCKED
查看阻塞态线程堆栈 • profiler
dump 线程栈,分析线程持锁情况
常见问题 3 :持续 FullGC 在了解 FullGC 原因之前,先花一点时间回顾下 jvm 的内存相关知识:
内存模型 内存模型 新 new 的对象放在 Eden 区,当 Eden 区满之后进行一次 MinorGC,并将存活的对象放入 S0; 当下一次 Eden 区满的时候,再次进行 MinorGC,并将存活的对象和 S0 的对象放入 S1(S0 和 S1 始终有一个是空的); 依次循环直到 S0 或者 S1 快满的时候将对象放入 old 区,依次,直到 old 区满进行 FullGC。
jdk1.7 之前 Java 类信息、常量池、静态变量存储在 Perm 永久代,类的原数据和静态变量在类加载的时候放入 Perm 区,类卸载的时候清理;在 1.8 中,MetaSpace 代替 Perm 区,使用本地内存,常量池和静态变量放入堆区,一定程度上解决了在运行时生成或加载大量类造成的 FullGC,如反射、代理、groovy 等。
回收器 回收器 年轻代常用 ParNew,复制算法,多线程并行; 老年代常用 CMS,标记清除算法(会产生内存碎片),并发收集(收集过程中有用户线程产生对象)。
关键常用参数 关键常用参数 CMSInitiatingOccupancyFraction 表示老年代使用率达到多少时进行 FullGC; UseCMSCompactAtFullCollection 表示在进行 FullGC 之后进行老年代内存整理,避免产生内存碎片。
问题原因及定位:
1 prommotion failed 从 S 区晋升的对象在老年代也放不下导致 FullGC(fgc 回收无效则抛 OOM)。
1)survivor 区太小,对象过早进入老年代。
jstat -gcutil pid 1000
观察内存运行情况; • jinfo pid
查看 SurvivorRatio 参数; 2)大对象分配,没有足够的内存。
日志查找关键字 “allocating large”• profiler 查看内存概况大对象分布;
3)old 区存在大量对象。
实例数量前十的类:
jmap -histo pid | sort -n -r -k 2 | head -10
实例容量前十的类:
jmap -histo pid | sort -n -r -k 3 | head -10
• dump 堆,profiler 分析对象占用情况 2 concurrent mode failed 在 CMS GC 过程中业务线程将对象放入老年代(并发收集的特点)内存不足。详细原因:
1)fgc 触发比例过大,导致老年代占用过多,并发收集时用户线程持续产生对象导致达到触发 FGC 比例。
• jinfo 查看 CMSInitiatingOccupancyFraction 参数,一般 70~80 即可 2)老年代存在内存碎片。
• jinfo 查看 UseCMSCompactAtFullCollection 参数,在 FullGC 后整理内存 常见问题 4 :线程池满 Java 线程池以有界队列的线程池为例,当新任务提交时,如果运行的线程少于 ,则创建新线程来处理请求。如果正在运行的线程数等于 corePoolSize 时,则新任务被添加到队列中,直到队列满。当队列满了后,会继续开辟新线程来处理任务,但不超过 maximumPoolSize。当任务队列满了并且已开辟了最大线程数,此时又来了新任务,ThreadPoolExecutor 会拒绝服务。
问题原因及定位:
1 下游 RT 高,超时时间不合理 高,超时时间不合理 业务监控 sunfire • eagleeye 2 数据库慢 sql 或者数据库死锁 或者数据库死锁 日志关键字 “Deadlock found when trying to get lock” • Jstack 或 zprofiler 查看阻塞态线程 3 Java 代码死锁 代码死锁 jstack –l pid | grep -i –E "BLOCKED | deadlock"
• dump thread 通过 zprofiler 分析阻塞线程和持锁情况
常见问题 5 :NoSuchMethodException 问题原因及定位:
1 jar 包冲突 包冲突 java 在装载一个目录下所有 jar 包时,它加载的顺序完全取决于操作系统。
mvn dependency:tree 分析报错方法所在的 jar 包版本,留下新的 arthas:sc -d ClassName • XX:+TraceClassLoading 2 同类问题 同类问题 ClassNotFoundException NoClassDefFoundError • ClassCastException 二 常用工具介绍 常用命令 1 tail • -f
跟踪文件 2 grep -i
忽略大小写 -v
反转查找 • -E
扩展正则表达式 :
grep -E "pattern1|pattern2" filename
3 pgm -b
开启-p
指定并发数 • -A
开启 askpass 4 awk • -F
指定分隔符:
awk -F “|”
"{print $1}‘ | sort -r | uniq -c
5 sed • 时间段匹配:
sed "/2020-03-02 10:00:00/,/2020-03-02 11:00:00/p" filename
arthas 阿里巴巴开源 Java 诊断工具(开源地址:https://github.com/alibaba/arthas),基于 javaAgent 方式,使用 Instrumentation 方式修改字节码方式进行 Java 应用诊断。
基础功能介绍 基础功能介绍 dashboard:系统实时数据面板, 可查看线程,内存,gc 等信息 thread:jvm 线程堆栈信息查看最繁忙的前 n 线程 • getstatic:获取静态属性值,如 getstatic className attrName 可用于查看线上开关真实值 sc:查看 jvm 已加载类信息,可用于排查 jar 包冲突 sm:查看 jvm 已的方法信息 jad:反编译 jvm 加载类信息,排查代码逻辑没执行原因 • watch:观测方法执行数据,包含出入参,异常等; watch xxxClass xxxMethod " {params, throwExp} "
-e -x 2
– watch xxxClass xxxMethod "{params,returnObj}" "params[0].sellerId.equals("189")" -x 2
– watch xxxClass xxxMethod sendMsg "@com.taobao.eagleeye.EagleEye@getTraceId()"
trace:方法内部调用时长,并输出每个节点的耗时,用于性能分析 • tt:用于记录方法,并做回放 三 常见问题恢复 1 线程池满 线程池满 • rpc 框架线程池满 – 高 RT 接口进行线程数限流 • 应用内线程池满 – 重启可短暂缓解,具体还得看问题原因 2 CPU 高,load 高 高 单机置换或重启,可短暂缓解 • 集群高且流量大幅增加,扩容,恢复看具体原因 3 下游 RT 高 高 限流 • 降级
4 数据库 数据库 • 死锁 – kill 进程 • 慢 sql – sql 限流 线上问题的排查是一个积累的过程,只有了解问题背后的原理才能更快速的定位和恢复,除此之外更需要有一些趁手的工具来辅助排查,从而降低整个团队问题定位和快恢的门槛。