参考：oom killer 详解

oom killer日志分析，这是前篇，准备一些基础知识

带着问题看：

1.什么是oom killer

是Linux内核设计的一种机制，在内存不足的时候，选择一个占用内存较大的进程并kill掉这个进程，以满足内存申请的需求（内存不足的时候该怎么办，其实是个两难的事情，oom killer算是提供了一种方案吧）

2.在什么时候触发？

前面说了，在内存不足的时候触发，主要牵涉到【linux的物理内存结构】和【overcommit机制】

2.1 内存结构 node、zone、page、order

对于物理内存内存，linux会把它分很多区（zone），zone上还有node的概念，zone下面是很多page，这些page是根据buddy分配算法组织的，看下面两张图：

image

image

上面的概念做下简单的介绍，对后面分析oom killer日志很有必要：

• Node：每个CPU下的本地内存节点就是一个Node，如果是UMA架构下，就只有一个Node0,在NUMA架构下，会有多个Node
• Zone：每个Node会划分很多域Zone，大概有下面这些：
  • 1. ZONE_DMA：定义适合DMA的内存域，该区域的长度依赖于处理器类型。比如ARM所有地址都可以进行DMA，所以该值可以很大，或者干脆不定义DMA类型的内存域。而在IA-32的处理器上，一般定义为16M。
  • 1. ZONE_DMA32：只在64位系统上有效，为一些32位外设DMA时分配内存。如果物理内存大于4G，该值为4G，否则与实际的物理内存大小相同。
  • 1. ZONE_NORMAL：定义可直接映射到内核空间的普通内存域。在64位系统上，如果物理内存小于4G，该内存域为空。而在32位系统上，该值最大为896M。
  • 1. ZONE_HIGHMEM：只在32位系统上有效，标记超过896M范围的内存。在64位系统上，由于地址空间巨大，超过4G的内存都分布在ZONE_NORMA内存域。
  • 1. ZONE_MOVABLE：伪内存域，为了实现减小内存碎片的机制。
  • 分配价值链
    • 除了只能在某个区域分配的内存（比如ZONE_DMA），普通的内存分配会有一个“价值”的层次结构，按分配的“廉价度”依次为：ZONE_HIGHMEM > ZONE_NORMAL > ZONE_DMA。
    • 即内核在进行内存分配时，优先从高端内存进行分配，其次是普通内存，最后才是DMA内存
• Page：zone下面就是真正的内存页了，每个页基础大小是4K，他们维护在一个叫free_area的数组结构中
  • order：数组的index，也叫order，实际对应的是page的大小，比如order为0，那么就是一堆1个空闲页（4K）组成的链表，order为1，就是一堆2个空闲页（8K）组成的链表，order为2，就是一堆4个空闲页（16K）组成的链表

2.2 overcommit

根据2.1，已经知道物理内存的大概结构以及分配的规则，不过实际上还有虚拟内存的存在，他的overcommit机制和oom killer有很大关系：

在实际申请内存的时候，比如申请1G，并不会在物理区域中分配1G的真实物理内存，而是分配1G的虚拟内存，等到需要的时候才去真正申请物理内存，也就是说申请不等于分配

所以说，可以申请比物理内存实际大的内存，也就是overcommit，这样会面临一个问题，就是当真的需要这么多内存的时候怎么办—>oom killer!

vm.overcommit_memory 接受三种值：

• 0 – Heuristic overcommit handling. 这是缺省值，它允许overcommit，但过于明目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存
• 1 – Always overcommit. 允许overcommit，对内存申请来者不拒。
• 2 – Don’t overcommit. 禁止overcommit。

3.oom killer 怎么挑选进程？

linux会为每个进程算一个分数，最终他会将分数最高的进程kill

• /proc/<pid>/oom_score_adj
  • 在计算最终的 badness score 时，会在计算结果是中加上 oom_score_adj，取值范围为-1000到1000
  • 如果将该值设置为-1000，则进程永远不会被杀死，因为此时 badness score 永远返回0。
• /proc/<pid>/oom_adj
  • 取值是-17到+15，取值越高，越容易被干掉。如果是-17，则表示不能被kill
  • 该设置参数的存在是为了和旧版本的内核兼容
• /proc/<pid>/oom_score
  • 这个值是系统综合进程的内存消耗量、CPU时间(utime + stime)、存活时间(uptime - start time)和oom_adj计算出的，消耗内存越多分越高，存活时间越长分越低
• 子进程内存：Linux在计算进程的内存消耗的时候，会将子进程所耗内存的一半同时算到父进程中。这样，那些子进程比较多的进程就要小心了。
• 其他参数（不是很关键，不解释了）
  • /proc/sys/vm/oom_dump_tasks
  • /proc/sys/vm/oom_kill_allocating_task
  • /proc/sys/vm/panic_on_oom
• 关闭 OOM killer
  • sysctl -w vm.overcommit_memory=2
  • echo "vm.overcommit_memory=2" >> /etc/sysctl.conf

3.1 找出最有可能被杀掉的进程

1. vi oomscore.sh
3. #!/bin/bash
4. for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do
5. printf "%2d %5d %s\n" \
6. "$(cat $proc/oom_score)" \
7. "$(basename $proc)" \
8. "$(cat $proc/cmdline | tr '\0' ' ' | head -c 50)"
9. done 2>/dev/null | sort -nr | head -n 10
11. chmod +x oomscore.sh
12. ./oomscore.sh
13. 18 981 /usr/sbin/mysqld
14. 4 31359 -bash
15. 4 31056 -bash
16. 1 31358 sshd: root@pts/6
17. 1 31244 sshd: vpsee [priv]
18. 1 31159 -bash
19. 1 31158 sudo -i
20. 1 31055 sshd: root@pts/3
21. 1 30912 sshd: vpsee [priv]
22. 1 29547 /usr/sbin/sshd -D

3.2 避免的oom killer的方案

• 直接修改/proc/PID/oom_adj文件，将其置位-17
• 修改/proc/sys/vm/lowmem_reserve_ratio
• 直接关闭oom-killer

参考：

• node & zone
• 理解LINUX的MEMORY OVERCOMMIT
• linux OOM-killer机制（杀掉进程，释放内存）
• Taming the OOM killer
• linux OOM 机制分析
• 理解和配置 Linux 下的 OOM Killer
• ubuntu 解决cache逐渐变大导致oom-killer将某些进程杀死的情况

二、oom killer理解和日志分析:日志分析

这篇是一例oom killer日志的具体分析,有疑问的可以先看上一篇：
oom killer理解和日志分析:知识储备i

下面是一台8G内存上的一次oom killer的日志，上面跑的是RocketMQ 3.2.6，java堆配置：-server -Xms4g -Xmx4g -Xmn2g -XX:PermSize=128m -XX:MaxPermSize=320m

1. Jun 4 17:19:10 iZ23tpcto8eZ kernel: AliYunDun invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
2. Jun 4 17:19:10 iZ23tpcto8eZ kernel: AliYunDun cpuset=/ mems_allowed=0
4. Jun 4 17:19:10 iZ23tpcto8eZ kernel: active_anon:1813257 inactive_anon:37301 isolated_anon:0 active_file:84 inactive_file:0 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:23900 slab_reclaimable:34218 slab_unreclaimable:5636 mapped:1252 shmem:100531 pagetables:68092 bounce:0 free_cma:0
6. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA free:15900kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
7. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 2801 7792 7792
9. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA32 free:43500kB min:24252kB low:30312kB high:36376kB
10. active_anon:2643608kB(2.5G) inactive_anon:61560kB active_file:40kB inactive_file:40kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3129216kB managed:2869240kB mlocked:0kB dirty:0kB writeback:0kB mapped:748kB shmem:160024kB slab_reclaimable:54996kB slab_unreclaimable:6816kB kernel_stack:704kB pagetables:67440kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:275 all_unreclaimable? yes
11. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 0 4990 4990
13. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 Normal free:36200kB min:43192kB low:53988kB high:64788kB
14. active_anon:4609420kB(4.3G) inactive_anon:87644kB active_file:296kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110124kB mlocked:0kB dirty:0kB writeback:0kB mapped:4260kB shmem:242100kB slab_reclaimable:81876kB slab_unreclaimable:15720kB kernel_stack:1808kB pagetables:204928kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:511 all_unreclaimable? yes
15. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 0 0 0
17. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15900kB
18. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA32: 1281*4kB (UEM) 825*8kB (UEM) 1404*16kB (UEM) 290*32kB (EM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 43468kB
19. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 Normal: 1441*4kB (UEM) 3177*8kB (UEM) 315*16kB (UEM) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 36220kB
20. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
22. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 100592 total pagecache pages
23. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 0 pages in swap cache
24. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Swap cache stats: add 0, delete 0, find 0/0
25. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Free swap = 0kB
26. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Total swap = 0kB
27. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 2097151 pages RAM
28. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 94167 pages reserved
29. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 284736 pages shared
30. Jun 4 17:19:10 iZ23tpcto8eZ kernel: 1976069 pages non-shared
32. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
33. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 338] 0 338 10748 844 25 0 0 systemd-journal
34. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 351] 0 351 26113 61 20 0 0 lvmetad
35. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 368] 0 368 10509 149 23 0 -1000 systemd-udevd
36. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 521] 0 521 170342 908 178 0 0 rsyslogd
37. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 525] 0 525 8671 82 21 0 0 systemd-logind
38. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 526] 81 526 7157 96 19 0 -900 dbus-daemon
39. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 530] 0 530 31575 162 17 0 0 crond
40. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 540] 28 540 160978 131 37 0 0 nscd
41. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 548] 0 548 27501 30 10 0 0 agetty
42. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 588] 0 588 1621 26 9 0 0 iprinit
43. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 590] 0 590 1621 25 9 0 0 iprupdate
44. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 601] 0 601 9781 23 8 0 0 iprdump
45. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 838] 38 838 7399 169 18 0 0 ntpd
46. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 881] 0 881 386 44 4 0 0 aliyun-service
47. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 5973] 1000 5973 41595 165 32 0 0 gmond
48. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 3829] 0 3829 33413 292 67 0 0 sshd
49. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 3831] 1000 3831 33582 476 68 0 0 sshd
50. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 3832] 1000 3832 29407 622 16 0 0 bash
51. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [14638] 0 14638 20697 210 42 0 -1000 sshd
52. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [11531] 0 11531 33413 293 66 0 0 sshd
53. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [11533] 1000 11533 33413 292 64 0 0 sshd
54. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [11534] 1000 11534 29361 584 15 0 0 bash
55. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 3172] 0 3172 6338 161 17 0 0 AliYunDunUpdate
56. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 3224] 0 3224 32867 2270 61 0 0 AliYunDun
57. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 5417] 1000 5417 28279 51 14 0 0 sh
58. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 5421] 1000 5421 28279 53 13 0 0 sh
59. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [ 5424] 1000 5424 36913689 1537770 66407 0 0 java
60. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17132] 0 17132 21804 215 44 0 0 zabbix_agentd
61. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17133] 0 17133 21804 285 43 0 0 zabbix_agentd
62. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17134] 0 17134 21866 290 44 0 0 zabbix_agentd
63. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17135] 0 17135 21866 290 44 0 0 zabbix_agentd
64. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17136] 0 17136 21841 290 44 0 0 zabbix_agentd
65. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [17137] 0 17137 21804 245 43 0 0 zabbix_agentd
66. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [13669] 1000 13669 28279 51 14 0 0 sh
67. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [13673] 1000 13673 28279 50 13 0 0 sh
68. Jun 4 17:19:10 iZ23tpcto8eZ kernel: [13675] 1000 13675 879675 204324 494 0 0 java
70. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Out of memory: Kill process 5424 (java) score 800 or sacrifice child
71. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Killed process 5424 (java) total-vm:147654756kB, anon-rss:6151080kB, file-rss:0kB

还是跟上篇一样，带着问题看

1.谁申请内存以及谁被kill了？

这两个问题，可以从头部和尾部的日志分析出来：

1. Jun 4 17:19:10 iZ23tpcto8eZ kernel: AliYunDun invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
2. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Killed process 5424 (java) total-vm:147654756kB, anon-rss:6151080kB, file-rss:0kB

AliYunDun申请内存，kill掉了java进程5424，他占用的内存是6151080K(5.8G)

还有一个小问题可能会有疑问，那就是进程5424的RSS（1537770）明明小于6151080，实际是因为这里的RSS是4K位单位的，所以要乘以4，算出来就对了

物理内存申请我们在上一篇分析了，会到不同的Node不同的zone，那么这次申请的是哪一部分？这个可以从gfp_mask=0x201da, order=0分析出来，gfp_mask(get free page)是申请内存的时候，会传的一个标记位，里面包含三个信息：区域修饰符、行为修饰符、类型修饰符：

1. 0X201da = 0x20000 | 0x100| 0x80 | 0x40 | 0x10 | 0x08 | 0x02
2. 也就是下面几个值：
3. ___GFP_HARDWAL | ___GFP_COLD | ___GFP_FS | ___GFP_IO | ___GFP_MOVABLE| ___GFP_HIGHMEM

同时设置了___GFP_MOVABLE和___GFP_HIGHMEM会扫描ZONE_MOVABLE，其实也就是会在ZONE_NORMAL，再贴一次神图

image

另外order表示了本次申请内存的大小0，也就是4KB
也就是说AliYunDun尝试从ZONE_NORMAL申请4KB的内存，但是失败了，导致了OOM KILLER

2.各个zone的情况如何？

接下来，自然就会问，连4KB都没有，那到底还有多少？看这部分日志：

1. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA free:15900kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
2. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 2801 7792 7792
4. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 DMA32 free:43500kB min:24252kB low:30312kB high:36376kB
5. active_anon:2643608kB(2.5G) inactive_anon:61560kB active_file:40kB inactive_file:40kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3129216kB managed:2869240kB mlocked:0kB dirty:0kB writeback:0kB mapped:748kB shmem:160024kB slab_reclaimable:54996kB slab_unreclaimable:6816kB kernel_stack:704kB pagetables:67440kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:275 all_unreclaimable? yes
6. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 0 4990 4990
8. Jun 4 17:19:10 iZ23tpcto8eZ kernel: Node 0 Normal free:36200kB min:43192kB low:53988kB high:64788kB
9. active_anon:4609420kB(4.3G) inactive_anon:87644kB active_file:296kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110124kB mlocked:0kB dirty:0kB writeback:0kB mapped:4260kB shmem:242100kB slab_reclaimable:81876kB slab_unreclaimable:15720kB kernel_stack:1808kB pagetables:204928kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:511 all_unreclaimable? yes
10. Jun 4 17:19:10 iZ23tpcto8eZ kernel: lowmem_reserve[]: 0 0 0 0

可以看到Normal还有36200KB，DMA32还有43500KB，DMA还有15900KB，其中Normal的free确实小于min，但是DMA32和DMA的free没问题啊？从上篇文章分析来看，分配是有链条的，Normal不够了，会从DMA32以及DMA去请求分配，所以为什么分配失败了呢？

2.1 lowmem_reserve

虽然说分配内存会按照Normal、DMA32、DMA的顺序去分配，但是低端内存相对来说更宝贵些，为了防止低端内存被高端内存用完，linux设计了保护机制，也就是lowmen_reserve，从上面的日志看，他们的值是这样的：

• DMA（index=0）: lowmem_reserve[]:0 2801 7792 7792
• DMA32（index=1）: lowmem_reserve[]: 0 0 4990 4990
• Normal（index=2）: lowmem_reserve[]: 0 0 0 0

lowmen_reserve的值是一个数组，当Normal(index=2)像DMA32申请内存的时候，需要满足条件：DMA32 high+lowmem_reserve[2] < free，才能申请，来算下：

• Normal：从自己这里申请，free(36200) < min(43192)，所以申请失败了(watermark[min]以下的内存属于系统的自留内存，用以满足特殊使用，所以不会给用户态的普通申请来用)
• Normal转到DMA32申请:high(36376KB) + lowmem_reserve[2](4990)*4=56336KB > DMA32 Free(43500KB),不允许申请
• Normal转到DMA申请:high(196KB) + lowmem_reserve[2](7792)*4 = 31364KB > DMA Free(15900KB),不允许申请,所以....最终失败了

2.2 min_free_kbytes

这里属于扩展知识了，和分析oom问题不大
我们知道了每个区都有min、low、high，那他们是怎么计算出来的，就是根据min_free_kbytes计算出来的，他本身在系统初始化的时候计算，最小128K，最大64M

• watermark[min] = min_free_kbytes换算为page单位即可，假设为min_free_pages。（因为是每个zone各有一套watermark参数，实际计算效果是根据各个zone大小所占内存总大小的比例，而算出来的per zone min_free_pages）
• watermark[low] = watermark[min] * 5 / 4
• watermark[high] = watermark[min] * 3 / 2

min 和 low的区别：

• min下的内存是保留给内核使用的；当到达min，会触发内存的direct reclaim
• low水位比min高一些，当内存可用量小于low的时候，会触发 kswapd回收内存，当kswapd慢慢的将内存 回收到high水位，就开始继续睡眠

3.最后的问题：java为什么占用了这么多内存？

内存不足申请失败的细节都分析清楚了，剩下的问题就是为什么java会申请这么多内存(5.8G)，明明-Xmx配置的是4G，加上PermSize，也就最多4.3G。

因为这上面跑的是RocketMQ，他会有文件映射mmap，所以在仔细分析oom日志之前，怀疑是pagecache占用，导致RSS为5.8G，这带来了另一个问题，为什么pagecache没有回收？分析了日志以后，发现和pagecache基本没关系，看这个日志(换行是我后来加上的)：

1. Jun 4 17:19:10 iZ23tpcto8eZ kernel: active_anon:1813257 inactive_anon:37301 isolated_anon:0 active_file:84
2. inactive_file:0 isolated_file:0
3. unevictable:0 dirty:0 writeback:0
4. unstable:0 free:23900
5. slab_reclaimable:34218
6. slab_unreclaimable:5636 mapped:1252
7. shmem:100531 pagetables:68092 bounce:0
8. free_cma:0

当时的内存大部分都是活跃的匿名页(active_anon 18132574KB=6.9G)，其他的非活跃匿名页（inactive_anon 145M），活跃文件页（active_file 844=336KB）,非活跃文件页（inactive_file 0），也就是说当时基本没有pagecache，因为pagecache会属于文件页

并且，这台机器上的gc log没配置好，进程重启以后gc文件被覆盖了，另外被oom killer也没有java dump，所以…..真的不知道到底为什么java占了5.8G!!! 悬案还是没有解开 T_T