新乡门户网站建设方案,做360网站优化,百度上怎么发布信息啊,南昌百恒信息技术有限公司前言本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知#xff0c;免得在遇到实际问题时手忙脚乱。毕竟作者自己也是从手忙脚乱时走过来的。只不过这里先提示一下。在线上应急过程中要记住#xff0c;只有一个…前言本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知免得在遇到实际问题时手忙脚乱。毕竟作者自己也是从手忙脚乱时走过来的。只不过这里先提示一下。在线上应急过程中要记住只有一个总体目标尽快恢复服务消除影响。不管处于应急的哪个阶段我们首先必须想到的是恢复问题恢复问题不一定能够定位问题也不一定有完美的解决方案也许是通过经验判断也许是预设开关等但都可能让我们达到快速恢复的目的然后保留部分现场再去定位问题、解决问题和复盘。在大多数情况下我们都是先优先恢复服务保留下当时的异常信息内存dump、线程dump、gc log等等在紧急情况下甚至可以不用保留等到事后去复现等到服务正常再去复盘问题。好现在让我们进入正题吧。常见现象CPU 利用率高/飙升场景预设监控系统突然告警提示服务器负载异常。预先说明CPU飙升只是一种现象其中具体的问题可能有很多种这里只是借这个现象切入。注CPU使用率是衡量系统繁忙程度的重要指标。但是CPU使用率的安全阈值是相对的取决于你的系统的IO密集型还是计算密集型。一般计算密集型应用CPU使用率偏高load偏低IO密集型相反。常见原因频繁 gc死循环、线程阻塞、io wait...etc模拟这里为了演示用一个最简单的死循环来模拟CPU飙升的场景下面是模拟代码在一个最简单的SpringBoot Web 项目中增加CpuReaper这个类/*** 模拟 cpu 飙升场景* author Richard_yyf*/
Component
public class CpuReaper {PostConstructpublic void cpuReaper() {int num 0;long start System.currentTimeMillis() / 1000;while (true) {num num 1;if (num Integer.MAX_VALUE) {System.out.println(reset);num 0;}if ((System.currentTimeMillis() / 1000) - start 1000) {return;}}}
}
打包成jar之后在服务器上运行。java -jar cpu-reaper.jar 第一步定位出问题的线程方法 a: 传统的方法top 定位CPU 最高的进程执行top命令查看所有进程占系统CPU的排序定位是哪个进程搞的鬼。在本例中就是咱们的java进程。PID那一列就是进程号。(对指示符含义不清楚的见【附录】)top -Hp pid 定位使用 CPU 最高的线程printf 0x%x tid 线程 id 转化 16 进制 printf 0x%x 12817 0x3211
jstack pid | grep tid 找到线程堆栈 jstack 12816 | grep 0x3211 -A 30
方法 b: show-busy-java-threads这个脚本来自于github上一个开源项目项目提供了很多有用的脚本show-busy-java-threads就是其中的一个。使用这个脚本可以直接简化方法A中的繁琐步骤。如下 wget --no-check-certificate https://raw.github.com/oldratlee/useful-scripts/release-2.x/bin/show-busy-java-threadschmod x show-busy-java-threads./show-busy-java-threads
show-busy-java-threads
# 从所有运行的Java进程中找出最消耗CPU的线程缺省5个打印出其线程栈
# 缺省会自动从所有的Java进程中找出最消耗CPU的线程这样用更方便
# 当然你可以手动指定要分析的Java进程Id以保证只会显示你关心的那个Java进程的信息
show-busy-java-threads -p 指定的Java进程Idshow-busy-java-threads -c 要显示的线程栈数
方法 c: arthas thread阿里开源的arthas现在已经几乎包揽了我们线上排查问题的工作提供了一个很完整的工具集。在这个场景中也只需要一个thread -n命令即可。 curl -O https://arthas.gitee.io/arthas-boot.jar # 下载
要注意的是arthas的cpu占比和前面两种cpu占比统计方式不同。前面两种针对的是Java进程启动开始到现在的cpu占比情况arthas这种是一段采样间隔内当前JVM里各个线程所占用的cpu时间占总cpu时间的百分比。具体见官网https://alibaba.github.io/arthas/thread.html后续通过第一步找出有问题的代码之后观察到线程栈之后。我们就要根据具体问题来具体分析。这里举几个例子。情况一发现使用CPU最高的都是GC 线程。GC task thread#0 (ParallelGC) os_prio0 tid0x00007fd99001f800 nid0x779 runnableGC task thread#1 (ParallelGC) os_prio0 tid0x00007fd990021800 nid0x77a runnable GC task thread#2 (ParallelGC) os_prio0 tid0x00007fd990023000 nid0x77b runnable GC task thread#3 (ParallelGC) os_prio0 tid0x00007fd990025000 nid0x77c runnabl
gc 排查的内容较多所以我决定在后面单独列一节讲述。情况二发现使用CPU最高的是业务线程io wait比如此例中就是因为磁盘空间不够导致的io阻塞等待内核态锁如 synchronizedjstack -l pid | grep BLOCKED 查看阻塞态线程堆栈dump 线程栈分析线程持锁情况。arthas提供了thread -b可以找出当前阻塞其他线程的线程。针对 synchronized 情况常见现象频繁 GC1. 回顾GC流程在了解下面内容之前请先花点时间回顾一下GC的整个流程。接前面的内容这个情况下我们自然而然想到去查看gc 的具体情况。方法a : 查看gc 日志方法b : jstat -gcutil 进程号 统计间隔毫秒 统计次数缺省代表一致统计方法c : 如果所在公司有对应用进行监控的组件当然更方便比如Prometheus Grafana这里对开启 gc log 进行补充说明。一个常常被讨论的问题惯性思维是在生产环境中GC日志是否应该开启。因为它所产生的开销通常都非常有限因此我的答案是需要开启。但并不一定在启动JVM时就必须指定GC日志参数。HotSpot JVM有一类特别的参数叫做可管理的参数。对于这些参数可以在运行时修改他们的值。我们这里所讨论的所有参数以及以“PrintGC”开头的参数都是可管理的参数。这样在任何时候我们都可以开启或是关闭GC日志。比如我们可以使用JDK自带的jinfo工具来设置这些参数或者是通过JMX客户端调用HotSpotDiagnostic MXBean的setVMOption方法来设置这些参数。这里再次大赞arthas❤️它提供的vmoption命令可以直接查看更新VM诊断相关的参数。获取到gc日志之后可以上传到GC easy帮助分析得到可视化的图表分析结果。2. GC 原因及定位prommotion failed从S区晋升的对象在老年代也放不下导致 FullGCfgc 回收无效则抛 OOM。可能原因survivor 区太小对象过早进入老年代查看 SurvivorRatio 参数大对象分配没有足够的内存dump 堆profiler/MAT 分析对象占用情况old 区存在大量对象dump 堆profiler/MAT 分析对象占用情况你也可以从full GC 的效果来推断问题正常情况下一次full GC应该会回收大量内存所以 正常的堆内存曲线应该是呈锯齿形。如果你发现full gc 之后堆内存几乎没有下降那么可以推断**堆中有大量不能回收的对象且在不停膨胀使堆的使用占比超过full GC的触发阈值但又回收不掉导致full GC一直执行。换句话来说可能是内存泄露了。一般来说GC相关的异常推断都需要涉及到内存分析使用jmap之类的工具dump出内存快照或者 Arthas的heapdump命令然后使用MAT、JProfiler、JVisualVM等可视化内存分析工具。至于内存分析之后的步骤就需要小伙伴们根据具体问题具体分析啦。常见现象线程池异常场景预设业务监控突然告警或者外部反馈提示大量请求执行失败。异常说明Java 线程池以有界队列的线程池为例当新任务提交时如果运行的线程少于 corePoolSize则创建新线程来处理请求。如果正在运行的线程数等于 corePoolSize 时则新任务被添加到队列中直到队列满。当队列满了后会继续开辟新线程来处理任务但不超过 maximumPoolSize。当任务队列满了并且已开辟了最大线程数此时又来了新任务ThreadPoolExecutor 会拒绝服务。常见问题和原因这种线程池异常一般可以通过开发查看日志查出原因有以下几种原因下游服务 响应时间RT过长这种情况有可能是因为下游服务异常导致的作为消费者我们要设置合适的超时时间和熔断降级机制。另外针对这种情况一般都要有对应的监控机制比如日志监控、metrics监控告警等不要等到目标用户感觉到异常从外部反映进来问题才去看日志查。数据库慢 sql 或者数据库死锁查看日志中相关的关键词。Java 代码死锁jstack –l pid | grep -i –E BLOCKED | deadlock四、常见问题恢复这一部分内容参考自此篇文章对于上文提到的一些问题这里总结了一些恢复的方法。五、Arthas这里还是想单独用一节安利一下Arthas这个工具。Arthas 是阿里巴巴开源的Java 诊断工具基于 Java Agent 方式使用 Instrumentation 方式修改字节码方式进行 Java 应用诊断。dashboard 系统实时数据面板, 可查看线程内存gc 等信息thread 查看当前线程信息查看线程的堆栈如查看最繁忙的前 n 线程getstatic获取静态属性值如 getstatic className attrName 可用于查看线上开关真实值sc查看 jvm 已加载类信息可用于排查 jar 包冲突sm查看 jvm 已加载类的方法信息jad反编译 jvm 加载类信息,排查代码逻辑没执行原因logger查看logger信息更新logger levelwatch观测方法执行数据包含出参、入参、异常等trace方法内部调用时长并输出每个节点的耗时用于性能分析tt用于记录方法并做回放以上内容节选自Arthas官方文档。另外Arthas里的 还集成了 ognl 这个轻量级的表达式引擎通过ognl你可以用arthas 实现很多的“骚”操作。其他的这里就不多说了感兴趣的可以去看看arthas的官方文档、github issue。六、涉及工具再说下一些工具。Arthasuseful-scriptsGC easySmart Java thread dump analyzer - thread dump analysis in secondsPerfMa - Java虚拟机参数/线程dump/内存dump分析Linux 命令Java N 板斧MAT、JProfiler...等可视化内存分析工具参考https://developer.aliyun.com/article/757655Arthas 3.2.0 文档《分布式服务架构原理、设计与实战》附录top 命令显示的指示符的含义指示符含义PID进程idUSER进程所有者PR进程优先级NInice值。负值表示高优先级正值表示低优先级VIRT进程使用的虚拟内存总量单位kb。VIRTSWAPRESRES进程使用的、未被换出的物理内存大小单位kb。RESCODEDATASHR共享内存大小单位kbS进程状态。D不可中断的睡眠状态 R运行 S睡眠 T跟踪/停止 Z僵尸进程%CPU上次更新到现在的CPU时间占用百分比%MEM进程使用的物理内存百分比TIME进程使用的CPU时间总计单位1/100秒COMMAND进程名称命令名/命令行来源 | https://ricstudio.top/archives/java-online-question-probe版权申明内容来源网络版权归原创者所有。除非无法确认我们都会标明作者及出处如有侵权烦请告知我们会立即删除并表示歉意。谢谢
