Arthas实践使用

1.启动

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar

按下前面对应的数字,即可成功启动

2.用途

  1. 实时监控:Arthas 可以实时监控 Java 应用程序的各种指标和状态,例如方法执行时间、线程情况、内存使用情况等。这使得开发人员能够深入了解应用程序的运行状况,并及时发现潜在的性能瓶颈和异常情况。

  2. 诊断问题:Arthas 提供了一系列的命令和工具,可以帮助开发人员诊断和分析应用程序中的问题。例如,它可以查看方法调用栈、查找资源泄漏、分析线程问题等。这有助于快速定位和解决应用程序的 bug 和性能问题。

  3. 动态修改代码:Arthas 具备动态修改 Java 代码的能力,开发人员可以在运行时修改已加载的类和方法,而无需重新编译和部署应用程序。这对于快速调试和排查问题非常有用。

  4. 命令行交互和可视化界面:Arthas 提供了命令行交互界面,开发人员可以通过命令行输入指令进行操作和查询。此外,Arthas 还提供了可视化界面(Arthas Web Console),方便开发人员在浏览器中查看和分析应用程序的运行数据。

3.自己常用的命令

3.1 watch

        可以通过这个命令监视某个方法的调用情况,并在方法被调用时实时显示方法参数和返回信息,通过编写 OGNL 表达式进行对应变量的查看。

        可以通过命令观察入参以及返回值

arthas@1]$ watch com.aurora.controller.CommentController listTopSixComments "{params,returnObj}" 
Press Q or Ctrl+C to abort.
Affect(class count: 2 , method count: 2) cost in 446 ms, listenerId: 1
method=com.aurora.controller.CommentController.listTopSixComments location=AtExit
ts=2023-06-17 08:23:36; [cost=73.790329ms] result=@ArrayList[
    @Object[][isEmpty=true;size=0],
    @ResultVO[ResultVO(flag=true, code=20000, message=操作成功, data=[CommentDTO(id=1032, userId=1024, nickname=木木夕, avatar=http://mumuxibucket.oss-cn-beijing.aliyuncs.com/aurora/avatar/e248edca7ebfac088b85d96fa3813ebc.png, webSite=null, commentContent=hello, createTime=2023-05-31T10:22:20, replyDTOs=null)])],
]

可以加上条件过滤

watch com.aurora.controller.CommentController listTopSixComments "{params,returnObj}" "params[0]=false"

还可以观察是否出现异常

watch com.aurora.controller.CommentController listTopSixComments "{params,throwExp}" -e -x 2

其他的一些参数

参数名称 参数说明
class-pattern 类名表达式匹配
method-pattern 函数名表达式匹配
express 观察表达式,默认值:{params, target, returnObj}
condition-express 条件表达式
[b] 函数调用之前观察
[e] 函数异常之后观察
[s] 函数返回之后观察
[f] 函数结束之后(正常返回和异常返回)观察
[E] 开启正则表达式匹配,默认为通配符匹配
[x:] 指定输出结果的属性遍历深度,默认为 1,最大值是 4
[m <arg>] 指定 Class 最大匹配数量,默认值为 50。长格式为[maxMatch <arg>]

3.2 trace

        一般用来查看方法路径上某个节点的耗时,可以进一步定位影响接口速度的方法。

[arthas@1]$ trace com.aurora.controller.CommentController listTopSixComments 
Press Q or Ctrl+C to abort.
Affect(class count: 2 , method count: 2) cost in 166 ms, listenerId: 5
`---ts=2023-06-17 08:33:48;thread_name=http-nio-8080-exec-5;id=26;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@7c214cc0
    `---[8.683509ms] com.aurora.controller.CommentController$$EnhancerBySpringCGLIB$$2f90009d:listTopSixComments()
        `---[98.89% 8.587255ms ] org.springframework.cglib.proxy.MethodInterceptor:intercept()
            `---[99.15% 8.514127ms ] com.aurora.controller.CommentController:listTopSixComments()
                +---[98.96% 8.425924ms ] com.aurora.service.CommentService:listTopSixComments() #52
                `---[0.14% 0.012228ms ] com.aurora.model.vo.ResultVO:ok() #52

3.3 jad

        反编译指定已加载类的源码,可以用来观察新上线的代码是否生效

jad com.aurora.controller.CommentController

3.4 thread

        关于thread命令,因为公司业务原因依赖于线程池的使用,以及线程用量较多,偶尔需要观察下线程的一些状态

  1. thread -all 展示全部线程
  2. thread -all | grep 't-' 根据字符串过滤
  3. thread -all | grep 't-' | wc -l  根据字符串过滤,统计数量
  1. 统计命令执行后的行数或者统计目录下文件数目(wc)
wc命令

常见参数如下:

-c 统计字节数。

-l 统计行数。

-m 统计字符数。这个标志不能与 -c 标志一起使用。

-w 统计字数。注意,这里的字指的是由空格,换行符等分隔的字符串。

例子:thread -all | grep 't-' | wc -l

关于线程出现CPU打满的问题的排查思路:

1个pod CPU打满与所有pod CPU打满应对策略与应对难度是不一样的,

1、第一考虑要素是止损,先将这个pod下线,
对于这个业务是数据异步处理对于时效性要求不高,可以等看是否能自动恢复,如果持续出现线程池打满可以考虑将这个pod下线,保留现场,不要重启pod,
2、任务量是否有没有变化
3、任务量没变化,是否有任务耗时比较多占用线程时间较长,例如:大租户集中发货等,
4、是否有线程阻塞,一直无法释放

可以先使用 ps、top等命令分析线程状态。

(1)使用 top 命令找到最耗CPU的线程ID :

        top –Hp PID

(2)将最耗CPU的线程ID转成16进制,因为线程快照文件中的线程编号是以16进制记录的:

        printf ‘%x \n’ PID

(3)将有问题的服务器下线,接着使用 jstack 导出线程快照信息,查看第(2)步中找出的线程ID正在进行什么操作:

        jstack pid |grep tid -A 30

可以通过jstack pid把全部线程信息打印出来,分析其中WAITING线程以及出现阻塞的地方

3.5 profiler

        火焰图分析

 
图中颜色代表
        绿色:Java代码
        黄色:JVM,C++代码
        红色:用户态,C代码
        橙色:内核态,C代码
图中x-y轴代表
        y 轴表示调用栈,每一层都是一个函数。调用栈越深,火焰就越高,顶部就是正在执行的函数,下方都是它的父函数。

        x 轴表示抽样数,如果一个函数在 x 轴占据的宽度越宽,就表示它被抽到的次数多,即执行的时间长。注意,x 轴不代表时间,而是所有的调用栈合并后,按字母顺序排列的。
栈宽含义(CPU时间)
宽度可以理解为CPU采样率的占比,越宽代表当前栈在采样数中占比高,当一个函数x轴越宽代表:
        该函数运行时间长
        该函数被调用次数多
平顶现象(一定要格外注意)
        平顶现象是由于当前程序的采样数在总采样数中占用过高导致的,出现这种现象需要特意关注一下程序具体的调用栈,采样比例占用率过高,即代表方法在CPU中的占用率过高

 欢迎大家访问:http://mumuxi.chat/

猜你喜欢

转载自blog.csdn.net/zz18532164242/article/details/131256521