性能文章>XPocket插件使用案例合集——性能问题排查分析,一个XPocket足以!>

XPocket插件使用案例合集——性能问题排查分析,一个XPocket足以!原创

https://a.perfma.net/img/3110416
10月前
4034010

你是否遇到过这些问题?

  • 系统存在性能问题
  • 问题排查时一头雾水,不知道用什么工具
  • 查找工具,下载和安装都很浪费时间
  • 排查问题十分繁琐,想尽量简化排查方案以供后续使用

XPocket是PerfMa开源的为终结性能问题而生的插件容器,它将定位或者解决各种性能问题的常见的Linux命令,JDK工具,知名性能工具等适配成各种XPocket插件,并让它们可以相互联动,一键解决特定的性能问题。

目前XPocket插件生态已经实现了HSDB、JDB、JConsole、Perf、Arthas等多个优秀的开源性能工具的插件化集成。XPocket支持JDK 8+,支持Linux/Mac/Windows,采用命令行交互模式,提供丰富的 Tab 自动补全功能,支持管道操作。

以下是XPocket官方提供的部分插件使用指南及真实案例。

1.XPocket插件jstack_x助力线程问题排查

https://heapdump.cn/article/2495088

在程序开发过程中,开发人员通常会遇到许多线上问题,这些问题可能是代码Bug导致的,也可能是性能问题引起的。这些线上问题都会通过CPU飙升、GC频繁、抛出OOM异常等情况表现出来,这些问题的根因很可能是由于线程或线程池使用不当造成的。为了尽快定位根因,可以使用jstack_x插件以线程为切入点进行排查。

XPocket插件jstack_x在JDK自带的jstack工具上进行了增强,除了支持java栈和本地栈的输出外,还可以从锁的角度查看等待或持有锁的线程,另外还可以通过线程名称和nid过滤出特定的线程

本文使用jstack_x插件分别排查了线程的CPU使用率飙升、无意中创建了超量的线程以及大量线程等待获取共享资源的问题,XPocket的jstack_x插件在JDK原有的jstack工具上做了增强,能够帮助每个开发者更加快速地排查定位出线程相关的问题。

jstack_x插件下载地址
https://plugin.xpocket.perfma.com/plugin/66
XPocket下载地址
https://xpocket.perfma.com/docs/download/

2.使用XPocket插件JConsole排查线上OOM异常案例

https://heapdump.cn/article/2630587

XPocket插件JConsole主要用于内存问题的排查,能够对堆中的Eden、Survivor、Old区以及堆外的Metaspace、Code Cache等区域进行观察

本文使用JConsole插件排查了频繁类加载引起OOM异常以及堆内存泄漏引起OOM异常的问题,JConsole能够排查Java进程内存的使用情况,特别是在排查过程中要进行多次打印,比对数值来发现问题。如果要进一步在代码级别定位问题,还可以使用XPocket中的其它插件进行辅助定位。

JConsole插件下载地址
https://plugin.xpocket.perfma.com/plugin/55

3.使用Perf插件跟踪进程切换信息

https://heapdump.cn/article/2641734

CPU使用率是最直观和最常用的系统性能指标,是在排查性能问题时会关注的第一个指标。而在导致CPU使用率过高的因素中,进程切换问题也是非常常见的。进程上下文切换次数较多的情况下,很容易导致CPU 将大量时间消耗在寄存器、内核栈、页表等资源的保存和恢复上,以至于导致系统性能不能充分利用。

但进程切换次数过多或切换次数异常的时候,针对C/C++程序调式手段非常有限,很难找到进程切换的原因,Perf插件本身可以跟踪进程切换调用栈并进行统计,本文借助一个简单例子验证了此插件的功能。

在碰到系统进程进程切换次数异常的问题时可以借助Perf插件,排查出具体函数。

Perf插件下载地址
https://plugin.xpocket.perfma.com/plugin/57

4.使用Top_X插件排查内存过载问题

https://heapdump.cn/article/2642770

Top命令是Linux 系统下常用的监控工具,用于实时获取进程级别的 CPU 或内存使用情况。

XPocket中的Top_X为Linux Top的增强版,可以显示CPU占用率/负载,CPU及内存进程使用的list。它对于繁杂的top命令输出进行了功能的拆分和整理,更加清晰易用,支持管道化,尤其可以直接拿到top进程或线程tid,pid; mem_s命令增加了按照进程swap大小占用排序增强了原有top功能

本文模拟一机器内存泄漏使用了大量物理内存导致物理内存飙升的情况。

在碰到内存过载问题时可以借助Top_X插件排查内存占用情况。

Top_X插件下载地址
https://plugin.xpocket.perfma.com/plugin/65

5.使用VJMap排查频繁YGC问题

https://heapdump.cn/article/2634094

分代版的jmap(新生代,存活区,老生代),是排查内存缓慢泄露,老生代增长过快原因的利器。因为jmap -histo PID 打印的是整个Heap的对象统计信息,而为了定位进程频繁YGC的问题,我们需要专门查看OldGen对象,和Survivor区大龄对象的工具。

本文首先使用VJMap插件查看了频繁YGC进程的年轻代的内存使用情况,然后结合HeapDump社区的XElephant工具进行dump文件分析,最后排查出了问题所在。

VJMap插件下载地址
https://plugin.xpocket.perfma.com/plugin/58
XPocket下载地址
https://xpocket.perfma.com/docs/download/

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
LONG究竟有多长,从皇帝的新衣到海康SDK
转眼之间初中毕业30年了,但我仍清楚的记得初中英语的一篇课文,题目叫《皇帝的新装》(“The king’s new clothes”)。这篇课文的前两句话是:”Long long ago, there
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm
JVM垃圾回收与一次线上内存泄露问题分析和解决过程
本文转载自:花椒技术微信公众号 前言内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。Ja
XPocket插件中心|JStack_X、Top_X插件上新,欢迎下载使用
为了给你带来更好的产品体验,请认真填写这份问卷:[XPocket插件中心调研问卷](XPocket插件中心调研问卷)你最想要我们在XPocket插件中心上新哪些插件?请在评论区留言、或填写问卷、或可以
记一次使用VJMap排查频繁YGC的经历
VJMap概述分代版的jmap(新生代,存活区,老生代),是排查内存缓慢泄露,老生代增长过快原因的利器。因为jmap -histo PID 打印的是整个Heap的对象统计信息,而为了定位上面的问题,我
XPocket插件使用案例合集——性能问题排查分析,一个XPocket足以!
你是否遇到过这些问题? - 系统存在性能问题 - 问题排查时一头雾水,不知道用什么工具 - 查找工具,下载和安装都很浪费时间 - 排查问题十分繁琐,想尽量简化排查方案以供后续使用XPocket是Per