帝国怎么做中英文网站,网站开发使用api对seo,wordpress 调用文章,自己可以建网站吗【实战场景】记一次UAT jvm故障排查经历 开篇词#xff1a;干货篇#xff1a;1.查看系统资源使用情况2.将十进制进程号转成十六进制3.使用jstack工具监视进程的垃圾回收情况4.输出指定线程的堆内存信息5.观察日志6.本地环境复现 总结篇#xff1a;我是杰叔叔#xff0c;一名… 【实战场景】记一次UAT jvm故障排查经历 开篇词干货篇1.查看系统资源使用情况2.将十进制进程号转成十六进制3.使用jstack工具监视进程的垃圾回收情况4.输出指定线程的堆内存信息5.观察日志6.本地环境复现 总结篇我是杰叔叔一名沪漂的码农下期再会 开篇词 故障背景是客服中心通话历史分表4季度单表200w查询一年的数据量大分页查询第20w页的10条数据查询多次tomcat卡死一段时间后后台其他定时任务kafaka消费线程恢复正常tomcat web容器依旧高cpu具卡无比。
干货篇
1.查看系统资源使用情况
top -H -p 49339 解释查看进程49339进程的实时系统资源使用情况“-H”表示查看进程中所有线程资源占用情况 “-p”指用来指定具体进程号
2.将十进制进程号转成十六进制
printf “%x \n” 49339 解释转换的目的是让这个线程ID能和jstack输出的线程ID匹配上因为jstack输出的是十六进制的线程ID
3.使用jstack工具监视进程的垃圾回收情况
jstat -gc 49339 3 5 解释通过jstat工具查看jvm 垃圾回收情况“-gc”指定要监视的内容为垃圾回收情况“3”每隔三秒输出一次监视结果“5”一共输出5次监视结果。
其中各参数代表的含义
S0C (Survivor space 0 capacity)第一个幸存区Survivor space的容量以字节为单位。幸存区用于存放垃圾收集后存活的对象。S1C (Survivor space 1 capacity)第二个幸存区的容量以字节为单位。在大多数 JVM 实现中幸存区有两个用于在不同的垃圾收集周期之间切换。S0U (Survivor space 0 utilization)第一个幸存区当前已使用的空间大小以字节为单位。S1U (Survivor space 1 utilization)第二个幸存区当前已使用的空间大小以字节为单位。EC (Eden space capacity)Eden 区的容量以字节为单位。Eden 区是 Java 堆的一部分用于存放新生成的对象。EU (Eden space utilization)Eden 区当前已使用的空间大小以字节为单位。OC (Old space capacity)老年代Old Generation的容量以字节为单位。老年代用于存放存活时间较长的对象。OU (Old space utilization)老年代当前已使用的空间大小以字节为单位。MC (Metaspace capacity)元空间MetaspaceJava 8 引入以替代永久代的容量以字节为单位。元空间用于存放类的元数据。MU (Metaspace utilization)元空间当前已使用的空间大小以字节为单位。CCSC (Compressed class space capacity)压缩类空间Java 8 中使用的容量以字节为单位。这个空间用于存放类的元数据但与元空间分开管理。CCSU (Compressed class space utilization)压缩类空间当前已使用的空间大小以字节为单位。YGC (Young GC count)年轻代垃圾收集的次数。YGCT (Young GC time)年轻代垃圾收集所花费的总时间以秒为单位。FGC (Full GC count)完全垃圾收集Full GC也称作老年代垃圾收集的次数。FGCT (Full GC time)完全垃圾收集所花费的总时间以秒为单位。GCT (Total GC time)垃圾收集所花费的总时间以秒为单位包括年轻代和完全垃圾收集的时间。 请注意具体的输出参数可能会因 JVM 的版本和配置如是否启用了压缩指针等而有所不同。此外对于 JDK 11 及更高版本元空间Metaspace取代了永久代PermGen space因此相关的参数如 PC 和 PU在较新版本的 JVM 中不再出现。
4.输出指定线程的堆内存信息
jmap -heap 49339 解释输出指定线程的堆内存信息
jstack -l 49339|grep c22a -A 20 解释时候用jstack工具来输出java进程的线程堆栈信息并查找包含字符串“c22a”的行打印其后面的20行 “-l”指定输出java进程的线程ID“-A 20”打印匹配行及其后面的20行
5.观察日志
发现kafka消费线程占用cpu较高kafka consumer正常epollWait等待kafaka数据无其他特别异常信息暂时跳过
6.本地环境复现
更换jdbc连接池至druid通过dashboard排查分表后的真实sql耗时中等数据量时由于分表的存在limit 20w20w10会被重写0,20W10以便跨表数据内存排序数据量大便造成了慢查询有可能导致OOM
总结篇
以下是大致的排查JVM问题的思路
初步观察和监控 查看系统指标使用系统监控工具如Linux的top命令或Windows的任务管理器查看CPU、内存和网络IO等关键指标。 观察JVM监控工具使用JDK自带的工具如jConsole、VisualVM或第三方工具如Arthas来远程连接并监控JVM的内存使用趋势、线程状态、垃圾回收活动等。确定问题类型 内存问题观察是否出现OutOfMemoryErrorOOM错误或者内存使用量异常增长。 CPU问题查看CPU使用率是否过高特别是某个或某些Java线程的CPU占用率异常。 线程问题检查是否存在死锁、线程饥饿或线程阻塞等问题。 垃圾回收问题分析垃圾回收日志查看垃圾回收的频率、时间和类型判断是否存在频繁的Full GC或GC时间过长等问题。使用诊断工具 jstack用于打印Java线程的堆栈跟踪信息帮助定位线程问题如死锁、线程阻塞等。 示例命令jstack 其中是Java进程的进程ID。 jmap用于生成堆内存快照和查询堆内存使用情况。 示例命令jmap -heap 查看堆内存使用情况jmap -dump:live,formatb,file.hprof 生成堆内存快照。 jstat用于监视JVM中类的加载、内存、垃圾收集、JIT编译等运行时数据。 示例命令jstat -gc 1000每1000毫秒打印一次GC信息。 jcmdJDK 1.8集成了多个JDK诊断命令的功能用于执行更复杂的诊断任务。 示例命令jcmd Thread.print打印线程信息。分析日志和堆内存快照 分析GC日志通过GC日志分析垃圾回收的频率、时间、类型和原因判断是否存在内存泄漏、堆内存设置不合理等问题。 分析堆内存快照使用MATMemory Analyzer Tool等内存分析工具分析堆内存快照查找内存泄漏的源头、大对象占用等。 查看应用程序日志检查应用程序日志以获取更多关于错误和异常的上下文信息。定位和解决问题 代码优化根据分析结果优化代码减少内存占用、避免内存泄漏、优化数据结构等。 JVM参数调整调整JVM启动参数如堆内存大小-Xms-Xmx、垃圾回收器类型-XX:UseG1GC等以改善JVM性能。 升级JDK版本如果问题是由于JDK的已知bug引起的考虑升级到更高版本的JDK。验证和监控 验证修复在开发或测试环境中验证修复是否有效确保问题得到解决。 持续监控在问题解决后持续监控系统性能确保没有新的问题出现。
通过以上步骤可以系统地排查和解决JVM问题提高系统的稳定性和性能。需要注意的是排查JVM问题可能需要一定的经验和耐心因为问题可能由多种因素引起需要综合考虑各种信息来找到问题的根源。 我是杰叔叔一名沪漂的码农下期再会
