JVM调优 - 用Arthas解决OOM问题

Posted 2021-06-20 zero13_小葵司

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JVM调优 - 用Arthas解决OOM问题相关的知识，希望对你有一定的参考价值。

上一篇：JVM调优 - 理解GC
接上一篇理解GC后，这一篇我们将讲解如何生产调优，或者说生产性能问题排查。

这一篇我们比较偏实际运用，就不过多去讲解一些原生指令或者java visualVm工具了。

java visualVm可以用于自己本地使用，或者测试环境调试，但是生产环境是不适用的，一是生产服务器基本不可能安装这个，二是本地连接进生产查看基本不可能，增加了网络安全风险。

所以我们这次主要讲一讲如何主要用Arthas做生产性能问题定位，并进行更新。

OOM

OOM是最常见的问题，如果FGC无法回收内存时，就会OOM了，有时可能不会引起注意，或者加大一下内存来解决，但是如果我们不去看看引起OOM的具体原因，可能很快又会发生OOM，或者依然会频繁FGC，FGC的STW是会比较久一些的，那么极端情况甚至可能引起微服务调用链路上的一系列超时甚至雪崩。

如何模拟OOM

我们不建议你在启动内存设置太小来模拟OOM，这样可能看不出太多东西。
OOM是怎么产生的？老年代被塞满了无法被回收，所以我们写一个循环，不停去创建新对象并让其被引用，使其不会被GC回收，这样我们就可以看到如何从eden到survivor到old，如何一个一个被填满。

使用Arthas

两个前置工作：

生产环境打开 HeapDumpOnOutOfMemoryError；
下载arthas；

我们不再去做arthas的介绍及安装讲解，这个大家可以去看官网，下载跑起来就可以。

用arthas关联到我们的目标项目后，使用如下命令：

dashboard

在这里可以看到：

显示进程内线程
线程组
优先级
消耗资源

在这里我们可以看到消耗资源最多的线程编号，然后可以看看该线程的细节：

thread 线程号

查看该进程内该线程具体信息，不过这里可能不一定需要查看这个，可以直接查看GC的日志，从GC日志进行分析，或者把GC信息dump出来（如果线上流量较大，最好将这台服务的流量断开），拿到本地或测试环境进行分析。

heapdump 目录地址

用上面的arthas命令相当于

jmap -dump:format=b,file=dump.prof 进程号

这个文件在本地有不少工具可以分析，如果dump出的文件较大，可以使用MAT进行线上分析。

我们通过GC日志找到是哪里引起的OOM后，可进行生产文件查看，使用以下命令：

sc -d 报错类

可以看到报错类的更多相关信息。

OOM主要原因

我们可以在dashboard里看到各堆内存区的使用情况，是确实流量太大应该加大内存还是大对象太多占满了老年代？

排查大对象

首先我们先根据文件信息看看是否业务逻辑写的有问题，生成了大量不合理的大对象。

如果是这个原因，我们可以修改代码后，做一下压测或者流量还原，内存使用明显下降或者FGC减少，那么说明修改有效。

并发较大

还有一种情况我们会看到survior区可能内容并不多，但是老年代上升很快，综合业务分析我们的对象大小以及每个对象的大概生存时间，有可能是该对象在扫描时还有被引用因此会从eden进入survior区，但是survior区不够大，因此直接进入了老年代，而下次GC时，该对象无法被回收，现象与上面有点像，但是处理上会有些不同。

这里的对象大小是何理的，因此我们的做法是加大新生代的内存大小，这样让该对象能够进入survior区，并在GC时能被回收。