服务器Docker OOM RSS高问题排查思路

优质博文：IT-BLOG-CN

防走弯路为防止走弯路，强烈建议先仔细阅读以下加粗内容：
如果你的应用是因为公司最近降成本调小实例物理内存才出现

docker oom

，而之前从来没有出现过，那么大概率是堆内存太大导致，这种情况尤其在实例物理内存

<=4G

的情况下多发。所以如果你的

case

满足以下场景，基本是堆内存设置不合理导致：
**【1】先看看你的应用

heap

实机用量，然后调小

xmx

到一个比较合理的数值，这里一定要自己定义xmx，不要用

ops

默认的计算值，因为那个计算值会把

xmx

设置为物理内存的

3/4

，对于小内存来说，这太大了；**
**【2】很多应用为了避免堆内存扩容导致性能下降，会将

xms

和

xms

设置成一样大，也会加剧小物理内存实例的

docker oom

。所以建议小内存实例把

xms

设置为物理内存的

1/2

或

1/3

；**
**【3】如果有的

group

有

oom

(比如

ALI

集群有

oom

)，有的一直没有，那么基本不是内存泄露导致，因为如果有内存泄露，那么任何集群都会出现

oom

。猜测这种情况因为实例底层参数差异导致(暂无法求证)，建议你把

oom

集群堆内存调小

256m

看看

oom

是否得到解决；**
【4】如果不满足上述两种情形，那就继续往下看吧；

一、前言

Java

进程使用的内存分为

3

部分：堆内存、虚拟机所使用的内存(一般叫

Native Memory

)、堆外内存(

off-heap

)组成。
【1】堆

heap

内存也就是你

jvm

参数里面设置的

xmx

和

xms

所指定的大小。如果你的工程里面的

extraenv.sh

没有指定

xms/xms

，那么

ops

会默认给你指定成物理内存的

3/4

。比如物理内存

4G

，那么堆内存会是

3072m

，这其实有点太大了；
【2】

Native memory

：虚拟机使用的内存，分为很多细分的区域，比如

class

、

gc

、

thread

、

code

、

internal

等；
名称作用描述Java Heap你所使用的堆内存Class元数据区，存储class信息，lambda表达式编译成的临时类也存放在这里面，可以通过-XX:MaxMetaspaceSize=256m限制大小Thread线程使用的内存区域, 用量可以简单的换算关系为线程数*xss。默认xss=1024k。如果你有1000个线程，那么Thread区可以占到1G。所以一般我们会设置xss=256kCodeJIT编译后的机器码所使用的区域GC垃圾回收器使用的内存区域，比如card table、RSet等。性能越好的垃圾回收器所占用的内存越大，另外如果你使用G1同时内存缓存了太多数据，那么G1也会占用很多的内存，因为它会把对象之间的引用关系放在RSet里面。CompilerJIT编译将class编译成机器码时所使用的临时区域Internal包含命令行解析器使用的内存、JVMTI、PerfData 以及 Unsafe 分配的内存等Other其他没有被覆盖到的区域SymbolSymbol 为 JVM 中的符号表所使用的内存，HotSpot中符号表主要有两种：SymbolTable 与 StringTable（字符串常量池）Native Memory TrackingNMT开启是有性能损耗的，这块区域就是JVM为Native Memory Tracking开辟的内存区域Arena ChunkJVM 分配的一些 Chunk（内存块），当退出作用域或离开代码区域时，内存将从这些 Chunk 中释放出来。然后这些 Chunk 就可以在其他子系统中重用. 需要注意的是，此时统计的 Arena 与 Chunk ，是 HotSpot 自己定义的 Arena、Chunk，而不是 Glibc 中相关的 Arena 与 Chunk 的概念LoggingJVM logging使用内存ArgumentsMemory for argumentsModuleMemory used by modules
服务器

RSS

过高会导致被拉出或者

OOM

，虽然各个公司现有的高可用机制能自动检测并通过进程重启的方式恢复服务，但我们需要知道

RSS

过高是什么原因导致的。本文会梳理一下

RSS

过高的排查套路，避免你走弯路。

首先，我们需要知道的是，

Java

进程消耗的内存绝不仅仅是你设置的

Xmx

这么简单，

Java

进程占用的内存分为

3

部分：堆内存、

JVM

自身消耗的内存、堆外内存。所以，后续的排查思路我们也是按照上面的

3

个方面来顺序展开。下图是各种

JVM

垃圾回收器消耗内存的比例，注意这部分内存是堆内存之外的：

实践证明，

G1

内存开销甚至能占到堆内存的

20%

，恐怖吧，惊喜不……

1 确认堆内存是否太大
首先要确认一下Java应用的堆内存是否太大，这个可以通过hickwall的appid docker linux tomcat多机模板 VM 查看。因为JVM自身也会消耗一些内存，所以你至少需要预留出部分内存存给JVM使用。如果应用涉及较多的网络通信，那还需要预留一些内存给堆外使用，所以一般来说你的堆内存最多为服务器物理内存减去1.2G，如4G服务器，那么堆内存最大为2.8G；(之前为3G，但就目前的趋势看，jvm自己用的内存也越来越多，所以这里调整成2.8G。当然这里是经验值，还是要结合你的应用所使用的堆内存决定)。
如果确认你的堆内存使用过多的话，那么问题相对简单了，我们可以通过dump堆内存，使用mat分析基本能定位到问题。这方面的问题很多，大家可以自行搜索。
2 确认是否DirectByteBuffer用量太大
我们知道，很多有网络交互的组件底层是基于netty或者nio的，而nio为了提高性能，会申请一部分堆外内存，有的是基于DirectByteBuffer申请的，如果网络交互频繁而且报文尺寸大，这部分内存的占用还是比较可观的，比如下面这个应用，DirectByteBuffer用量都能达到700m。

需要注意的是：Java对于DirectByteBuffer的用量是没有做限制的，也就是它可以申请物理内存那么多的用量。所以如果你的DirectByteBuffer用量比较多，可以通过在jvm参数中设置-XX:MaxDirectMemorySize这个参数控制一下。在DirectByteBuffer用量超过你设置的大小时，系统会触发一次System.gc()(未必是FGC)。
3 确认是否存在大量ARENA区
如果堆内存不大，那么继续排查非堆内存。首先我们去看一下ARENA区。在高并发的应用中，往往ARENA区占用的内存会比较多。至于ARENA是什么东东，可以读一下这篇文章：https://blog.csdn.net/maokelong95/article/details/51989081
执行如下命令：

sudo -u deploy pmap -x <pid>|sort -gr -k2 |less 

如果存在大量大小为

65536

或

65404

的内存区域，则说明

ARENA

区域占用了太多的内存，如下图所示：

这种情况下，有2个选择：内存分配器换成jemalloc，详情见：jemalloc 服务 ( http://conf.ctripcorp.com/pages/viewpage.action?pageId=1131500186 )粗暴的办法是修改环境变量的值，在extraenv.sh中添加这么一行：export MALLOC_ARENA_MAX=1需要注意的是，上述的数值只能是1，其他大于1的数值经实践证明是无法控制ARENA数量的。4 确认Native Memory开销过大如果前面2个步骤看到的内存开销都不大，还有很多内存区域你不知道消耗在哪里了，那么我们开始第三步：开启Native Memory Tracking。前面我们说过，Java应用的执行，JVM自身也需要消耗一些内存的，通过开启Native Memory Tracking，我们就能知道JVM自身消耗了多少内存。请不要迷信vi里面的非堆内存消耗，那是不准确的……书归正传，通过修改/opt/tomcat/bin/setenv.sh中的JVM参数并重启Java进程开启：

-XX:NativeMemoryTracking=detail 

进程重启后，可以通过以下命令查看NativeMemory的占用情况：

sudo -Esu deploy /usr/java/default/bin/jcmd <pid> VM.native_memory summary 

你会看到以下类似的执行结果：

通过上图，你可以看到JVM各个区域所使用的内存大小，主要包含了Java Heap、Class、Thread、Code、GC、Compiler、Internal、Other、Symbol、Native Memory Tracking、Arena Chunk这几部分。
需要注意的是Class、Thread、GC几个区域的大小。
上面的图片是27G的堆内存，使用G1回收器，你能看到GC区居然占用了3.8G的内存。
针对上面的各个区域大小做加法，看一下是否接近于RSS的大小，如果是，恭喜你可以到此结束了。后续你需要做的就是针对内存占用比较大的JVM区去做优化，这里就不详细介绍了。
如果不是，很遗憾，你进入到了最难啃的环节，继续往下看吧。

需要注意的是，开启NativeMemoryTracking会造成5%的性能下降，用完记得关闭。
可以通过以下命令临时关闭：

sudo -Esu deploy /usr/java/default/bin/jcmd <pid> VM.native_memory stop 

或者修改/opt/tomcat/bin/setenv.sh中的JVM参数并重启永久关闭。

如果你嫌上面的文章安装配置比较麻烦，你也可以用我的jtoolkit去排查，安装命令很简单：

curl -L http://devresources.flight.ctripcorp.com/jtoolkit/shells/install.sh|bash 

安装完毕，根据提示去使用就可以了，希望通过上面的介绍，能解决你的问题。

如果很不幸你的问题还没有得到解决的话，那么抱歉，这超出了我的认知了。