jvm性能调优实战 - 49OOM异常进行监控以及online处理

Pre

一旦发生了各种场景下的OOM，我们到底应该如何处理呢？ 所以j继续将会从OOM问题的监控开始，给大家讲OOM的排查、定位和解决的一系列思路

最佳的解决方案

先给大家说一种最佳的OOM监控方案，其实说白了也很简单， 公司最好是应该有一种监控平台，比如Zabbix、Open-Falcon之类的监控平台。

如果有监控平台的话，就可以接入系统异常的一些监控和报警，你可以设置一旦系统出现了OOM异常，就发送报警给对应的开发人员，通过邮件、短信或者钉钉之类的IM工具。

这个是中大型公司里最常用的一种方案了，一般来说我们都对线上系统有以下几个层面的监控：

机器（CPU、磁盘、内存、网络）资源的负载情况，JVM的GC频率和内存使用率，系统自身的业务指标，系统的异常报错。

这些东西都会基于监控平台接入对应的监控项，同时设定关键监控项的一些报警阈值。

一个比较成熟的系统监控体系的建议

首先通过监控平台是可以看到你的所有线上系统所在的机器资源的负载情况的，比如CPU负载，这个可以看到现在你的CPU目前的使用率有多高，比如你的CPU使用率都达到100%了，此时一定有问题了，你得检查一下为什么CPU负载那么高。

而且可以看到你的机器上磁盘IO的一些负载，包括磁盘上发生了多少数据量的IO，一些IO的耗时等等。

当然一般的业务系统本身不会直接读写自己本地的磁盘IO，最多就是写一些本地日志而已。

但是你应该关注的是你本地磁盘的使用量和剩余空间，因为有的系统因为一些代码bug，可能会一直往本地磁盘写东西，万一把你的磁盘空间写满了就麻烦了，这样也会导致你的系统无法运行。

其次可以看到你机器上的内存使用量，这个是从机器整体层面去看的，看看机器对内存使用的一些变化。

当然内存这块，比较核心的还是JVM这块的监控，我们是可以看到JVM各个内存区域的使用量的一个变化的。

最后就是机器上的网络负载，就是通过网络IO读写了多少数据，一些耗时，等等。

还有一个比较关键的，就是JVM的Full GC的频率，这个一般会用一段时间内的Full GC次数来监控，比如5分钟内发生了几次Full GC。

其实线上机器最容易出问题的主要三大块，一个是CPU，必须要对CPU的使用率做一个监控，如果CPU负载过高，比如长期使用率超过90%，就得报警了；

一个是内存，同样得监控内存的使用率，如果机器内存长期使用率超过了一定的阈值，比如长期使用率超过90%，那肯定是有问题的，随时机器内存可能就不够了；

一个是JVM的Full GC问题，假设5分钟内发生了10次Full GC，那一定是频繁F