系统内存耗尽的案例分析

近日遇到一个RAC节点hang导致节点被重启的问题，最后经过分析，发现在系统运行一段时间后，系统内存就会耗尽，原本256G的内存，最后只剩几百M。

1. 问题时间段的TOP输出可以看到，内存只剩7G，而分析内存问题，TOP输出是不够的，一般情况下，Database的SGA和PGA是内存使用大户，所以，在TOP很难发现谁是使用内存最多的。

除非某些进程内存使用的格外明显

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Linux OSWbb v7.3.3zzz ***Tue Feb 21 00:00:10 CST 2017top - 00:00:12 up 14:16, 10 users,  load average: 2.97, 2.31, 2.05Tasks: 3087 total,  11 running, 3076 sleeping,   0 stopped,   0 zombieCpu(s): 11.7%us,  2.8%sy,  0.0%ni, 83.7%id,  0.9%wa,  0.0%hi,  0.9%si,  0.0%stMem:    257948M total,   250464M used,     7484M free,      113M buffersSwap:    65537M total,        0M used,    65537M free,    59868M cachedPID USER      PR  NI  VIRT  RES  SHR S   %CPU %MEM    TIME+  COMMAND1156 oracle    20   0  4232  568  380 R    101  0.0   0:01.67 gzip20019 root      RT   0  308m  89m  57m S     13  0.0  24:09.96 osysmond.bin1160 oracle    20   0 11252 3492  836 R      9  0.0   0:00.17 top49793 oracle    20   0  128g 1.2g 1.2g S      7  0.5  36:00.74 oracle~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2. 通过AWR，可以看到数据库很忙

3. 但是Oracle的物理内存使用百分比只有33%，并不是oracle耗尽的主机内存。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Memory Statistics    Begin    EndHost Mem (MB):    257,948.4    257,948.4SGA use (MB):    77,824.0    77,824.0PGA use (MB):    8,938.9    6,416.3% Host Mem used for SGA+PGA:    33.64    32.66~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4. 注意：一般情况下Oracle的全部进程，如smon, pmon,lgwr等，都会分别使用SGA， PGA，以及一小部分内存作为进程本身使用（这部分一般很小）。

所以，这里的33%，可以代表Oracle全部使用的物理内存。

当然，出现一些bug的情况，如LMS异常使用内存等情况，就另当别论了。

参考案例：RAC: LMS uses huge memory (Doc ID 1954701.1)RAC LMS processes using huge PGA memory:SQL> select pid,spid,program,pga_used_mem,pga_alloc_mem,pga_freeable_mem,pga_max_mem from v$process where program like '%LMS%';PID SPID USER PROGRAM PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM---------- ------------------------ --------------- ------------------------------------------------ ------------13 23698 oracle@grid06.prod.quova.com (LMS0) 1.0644E+10 1.6525E+10 0 1.6525E+1014 23702 oracle@grid06.prod.quova.com (LMS1) 1.0644E+10 1.6525E+10 0 1.6525E+1015 23706 oracle@grid06.prod.quova.com (LMS2) 1.0407E+10 1.6157E+10 0 1.6157E+1016 23710 oracle@grid06.prod.quova.com (LMS3) 1.0599E+10 1.6455E+10 0 1.6455E+10其中涉及BUG 16412220 - DLM USES EXCEESIVE PGA SEND MBUFS AND NOT RELEASE BACK TO PGA MEMORY POOL

5. 分析过程中，也确认了一下，PGA曾经使用过的最大内存情况，可以看到PGA最大也就是使用10G，对应256G物理内存来说，很少。不是问题点

select * from dba_hist_pgastat  SNAP_ID DBID INSTANCE_NUMBER NAME    VALUE     1054  602741423    1 aggregate PGA target parameter       5.5835E+10     1054  602741423    1 aggregate PGA auto target       4.3041E+10     1054  602741423    1 global memory bound       1073741824     1054  602741423    1 total PGA inuse       8010343424     1054  602741423    1 total PGA allocated       9373099008     1054  602741423    1 maximum PGA allocated       1.0711E+10     1054  602741423    1 total freeable PGA memory 396361728     1054  602741423    1 process count     2232     1054  602741423    1 max processes count     3053     1054  602741423    1 PGA memory freed back to OS       6.3224E+11     1054  602741423    1 maximum PGA used for auto workareas  5028864     1054  602741423    1 maximum PGA used for manual workareas   542720     1054  602741423    1 bytes processed       1036738560     1054  602741423    1 cache hit percentage      100     1054  602741423    1 recompute count (total)     7478   1055  602741423    2 aggregate PGA target parameter       4.8050E+10     1055  602741423    2 aggregate PGA auto target       3.7282E+10     1055  602741423    2 global memory bound       1073741824     1055  602741423    2 total PGA inuse       6643825664     1055  602741423    2 total PGA allocated       7995835392     1055  602741423    2 maximum PGA allocated       9677304832     1055  602741423    2 total freeable PGA memory 420085760     1055  602741423    2 process count     2107     1055  602741423    2 max processes count     2365     1055  602741423    2 PGA memory freed back to OS       8.2417E+11     1055  602741423    2 maximum PGA used for auto workareas 33622016     1055  602741423    2 maximum PGA used for manual workareas   542720     1055  602741423    2 bytes processed       1.3889E+10     1055  602741423    2 cache hit percentage      100     1055  602741423    2 recompute count (total)     8519Line 384:        997  602741423    2 maximum PGA allocated       1.0699E+10Line 967:        998  602741423    2 maximum PGA allocated       1.0699E+10   <<<<<<<<<<<<<<<10GLine 1380:        983  602741423    1 maximum PGA allocated       1.0598E+10Line 1436:        986  602741423    1 maximum PGA allocated       1.1655E+10Line 1808:       1056  602741423    1 maximum PGA allocated       1.1055E+10Line 2029:        997  602741423    1 maximum PGA allocated       1.3501E+10Line 2350:       1018  602741423    1 maximum PGA allocated       1.0049E+10Line 2376:        985  602741423    1 maximum PGA allocated       1.1624E+10

6. 最后，查看meminfo，发现了问题，PageTables占用了168G的内存, 加上SGA和PGA的使用，刚刚好250G左右。

PageTables是内存表，是不共享的，在内存很大的情况下，如果很大process访问内存的话，就会每个process都copy一份PageTables，最终导致大量内存自耗的情况

node3_meminfo_17.02.21.0000.datzzz ***Tue Feb 21 00:00:10 CST 2017MemTotal:       264139120 kB  ===> 260 GBMemFree:         7720156 kB   ===> 7 GBBuffers:          116576 kBCached:         60954824 kB  ===> 60GB (include SGA)SwapCached:            0 kBActive:         61768656 kBInactive:       12761292 kBActive(anon):   61284872 kB  ===>Inactive(anon): 11620960 kBActive(file):     483784 kB  ===> 500 MBInactive(file):  1140332 kB   ===> 1GBUnevictable:      333944 kBMlocked:          223568 kBSwapTotal:      67110908 kBSwapFree:       67110780 kBDirty:              3764 kBWriteback:             0 kBAnonPages:      13793504 kBMapped:         58621868 kBShmem:          59376696 kB  Slab:            1354844 kB   ===> 1 GBSReclaimable:     351496 kBSUnreclaim:      1003348 kBKernelStack:       29248 kBPageTables:     176260660 kB  ===> 168 GBNFS_Unstable:          0 kBBounce:                0 kBWritebackTmp:          0 kBCommitLimit:    199180468 kBCommitted_AS:   88076096 kB

关于PageTables，参考下图

7. 检查之前正常时间段的meminfo，可以发现，刚启动数据库时，PageTables只有700M，但是随着进程的增加，很快PageTables就增长上来了

meminfo_17.02.20.1400.datzzz ***Mon Feb 20 14:19:05 CST 2017MemTotal:       264139120 kBMemFree:        222005744 kBBuffers:          112332 kBSUnreclaim:       258840 kBKernelStack:       11320 kBPageTables:       747560 kB   <<<<<<<<<<<<<<
8. 既然问题找到了，如何解决呢？
Hugepages是解决这种问题的最好方案。
hugepages的内存块是2M（普通内存块是4K），首先内存管理的成本就降低500倍，而且hugepages的内存表是可以共享的。

9. 最终，配置hugepages，解决问题。
相关hugepages文档，请参考另两篇blog
Hugepages你用了吗？----原理概念篇
Hugepages你用了吗？----测试案例篇

题外话，oswatcher是Oracle分析和解决问题，非常有用的一个工具，在很多问题的分析上，都能提供很大的帮助。 所以强烈建议部署。