java故障排查-Java线上故障排查必备指南（完整版）（1）.pdfVIP

java故障排查_Java线上故障排查必备指南（完整版）（1） 线上故障主要会包括 CPU、磁盘、内存以及⽹络问题，⽽⼤多数故障可能会包含不⽌⼀个层⾯的问题，所以进⾏排查时候尽量四个⽅⾯依 次排查⼀遍。同时例如 jstack、jmap 等⼯具也是不囿于⼀个⽅⾯的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、 jmap 伺候，具体问题具体分析即可。 CPU⼀般来讲我们⾸先会排查 CPU ⽅⾯的问题。CPU 异常往往还是⽐较好定位的。原因包括业务逻辑问题(死循环)、频繁 gc 以及上下⽂ 切换过多。⽽最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使⽤ jstack 来分析对应的堆栈情况。使⽤ jstack 分析 CPU 问题我们 先⽤ ps 命令找到对应进程的 pid(如果你有好⼏个⽬标进程，可以先⽤ top 看⼀下哪个占⽤⽐较⾼)。 接着⽤top -H -p pid来找到 CPU 使⽤率⽐较⾼的⼀些线程 然后将占⽤最⾼的 pid 转换为 16 进制printf %x\n pid得到 nid 接着直接在 jstack 中找到相应的堆栈信息jstack pid |grep nid -C5 –color 可以看到我们已经找到了 nid 为 0x42 的堆栈信息，接着只要仔细分析⼀番即可。当然更常见的是我们对整个 jstack ⽂件进⾏分析，通常 我们会⽐较关注 WAITING 和 TIMED_WAITING 的部分，BLOCKED 就不⽤说了。我们可以使⽤命令cat jstack.log | grep java.lang.Thread.State | sort -nr | uniq -c来对 jstack 的状态有⼀个整体的把握，如果 WAITING 之类的特别多，那么多半是有问题 啦。 频繁 gc当然我们还是会使⽤ jstack 来分析问题，但有时候我们可以先确定下 gc 是不是太频繁，使⽤jstat -gc pid 1000命令来对 gc 分 代变化情况进⾏观察，1000 表⽰采样间隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU 分别代表两个 Survivor 区、 Eden 区、⽼年代、元数据区的容量和使⽤量。YGC/YGT、FGC/FGCT、GCT 则代表 YoungGc、FullGc 的耗时和次数以及总耗时。如 果看到 gc ⽐较频繁，再针对 gc ⽅⾯做进⼀步分析，具体可以参考⼀下 gc 章节的描述。 上下⽂切换针对频繁上下⽂问题，我们可以使⽤vmstat命令来进⾏查看 cs(context switch)⼀列则代表了上下⽂切换的次数。 如果我们希望对特定的 pid 进⾏监控那么可以使⽤ pidstat -w pid命令，cswch 和 nvcswch 表⽰⾃愿及⾮⾃愿切换。 磁盘 磁盘问题和 CPU ⼀样是属于⽐较基础的。⾸先是磁盘空间⽅⾯，我们直接使⽤df -hl来查看⽂件系统状态 更多时候，磁盘问题还是性能上的问题。我们可以通过 iostatiostat -d -k -x来进⾏分析 最后⼀列%util可以看到每块磁盘写⼊的程度，⽽rrqpm/s以及wrqm/s分别表⽰读写速度，⼀般就能帮助定位到具体哪块磁盘出现问题 了。 另外我们还需要知道是哪个进程在进⾏读写，⼀般来说开发⾃⼰⼼⾥有数，或者⽤ iotop 命令来进⾏定位⽂件读写的来源。 不过这边拿到的是 tid，我们要转换成 pid，可以通过 readlink 来找到 pidreadlink -f /proc/*/task/tid/../..。 找到 pid 之后就可以看这个进程具体的读写情况cat /proc/pid/io 我们还可以通过 lsof 命令来确定具体的⽂件读写情况lsof -p pid 内存 内存问题排查起来相对⽐ CPU ⿇烦⼀些，场景也⽐较多。主要包括 OOM、GC 问题和堆外内存。⼀般来讲，我们会先⽤free命令先来检 查⼀发内存的各种情况。 堆内内存 内存问题⼤多还都是堆内内存问题。表象上主要分为 OOM 和 Stack Overflo。 OOM JMV 中的内存不⾜，OOM ⼤致可以分为以下⼏种： Exception in thread main java.lang.OutOfMemoryError: unable to create new native thread 这个意思是没有⾜够的内存空间给线程分配 Java 栈，基本上还是线程池代码写的有问题，⽐如说忘记 shutdown，所以说应该⾸先从代码 层⾯来寻找问题，使⽤ jstack 或者 jmap。如果⼀切都正常，JVM ⽅⾯可