服务器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等；
| 名称 | 作用描述 |
|---|
