系统内存耗尽的案例分析-低调大师

系统内存耗尽的案例分析

2017-02-23 583

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

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

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Linux OSWbb v7.3.3
zzz ***Tue Feb 21 00:00:10 CST 2017
top - 00:00:12 up 14:16, 10 users,  load average: 2.97, 2.31, 2.05
Tasks: 3087 total,  11 running, 3076 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.7%us,  2.8%sy,  0.0%ni, 83.7%id,  0.9%wa,  0.0%hi,  0.9%si,  0.0%st
Mem:    257948M total,   250464M used,     7484M free,      113M buffers
Swap:    65537M total,        0M used,    65537M free,    59868M cached
PID USER      PR  NI  VIRT  RES  SHR S   %CPU %MEM    TIME+  COMMAND
1156 oracle    20   0  4232  568  380 R    101  0.0   0:01.67 gzip
20019 root      RT   0  308m  89m  57m S     13  0.0  24:09.96 osysmond.bin
1160 oracle    20   0 11252 3492  836 R      9  0.0   0:00.17 top
49793 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    End
Host Mem (MB):    257,948.4    257,948.4
SGA use (MB):    77,824.0    77,824.0
PGA 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+10
14 23702 oracle@grid06.prod.quova.com (LMS1) 1.0644E+10 1.6525E+10 0 1.6525E+10
15 23706 oracle@grid06.prod.quova.com (LMS2) 1.0407E+10 1.6157E+10 0 1.6157E+10
16 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)     8519
Line 384:        997  602741423    2 maximum PGA allocated       1.0699E+10
Line 967:        998  602741423    2 maximum PGA allocated       1.0699E+10   <<<<<<<<<<<<<<<10G
Line 1380:        983  602741423    1 maximum PGA allocated       1.0598E+10
Line 1436:        986  602741423    1 maximum PGA allocated       1.1655E+10
Line 1808:       1056  602741423    1 maximum PGA allocated       1.1055E+10
Line 2029:        997  602741423    1 maximum PGA allocated       1.3501E+10
Line 2350:       1018  602741423    1 maximum PGA allocated       1.0049E+10
Line 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.dat
zzz ***Tue Feb 21 00:00:10 CST 2017
MemTotal:       264139120 kB  ===> 260 GB
MemFree:         7720156 kB   ===> 7 GB
Buffers:          116576 kB
Cached:         60954824 kB  ===> 60GB (include SGA)
SwapCached:            0 kB
Active:         61768656 kB
Inactive:       12761292 kB
Active(anon):   61284872 kB  ===>
Inactive(anon): 11620960 kB
Active(file):     483784 kB  ===> 500 MB
Inactive(file):  1140332 kB   ===> 1GB
Unevictable:      333944 kB
Mlocked:          223568 kB
SwapTotal:      67110908 kB
SwapFree:       67110780 kB
Dirty:              3764 kB
Writeback:             0 kB
AnonPages:      13793504 kB
Mapped:         58621868 kB
Shmem:          59376696 kB  
Slab:            1354844 kB   ===> 1 GB
SReclaimable:     351496 kB
SUnreclaim:      1003348 kB
KernelStack:       29248 kB
PageTables:     176260660 kB  ===> 168 GB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    199180468 kB
Committed_AS:   88076096 kB

关于PageTables，参考下图

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

meminfo_17.02.20.1400.dat
zzz ***Mon Feb 20 14:19:05 CST 2017
MemTotal:       264139120 kB
MemFree:        222005744 kB
Buffers:          112332 kB
SUnreclaim:       258840 kB
KernelStack:       11320 kB
PageTables:       747560 kB   <<<<<<<<<<<<<<<
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
Line 1113: PageTables:       752060 kB
Line 1157: PageTables:       769128 kB
Line 1201: PageTables:       769252 kB
Line 1245: PageTables:       758068 kB
Line 1289: PageTables:      2995368 kB   <<<<<<<<<<<<<<<<<
Line 1333: PageTables:      4314036 kB
Line 1377: PageTables:      5717752 kB
Line 1421: PageTables:      6107780 kB
Line 1465: PageTables:      6427636 kB
Line 1509: PageTables:      7307184 kB
Line 1553: PageTables:      8552708 kB
Line 1597: PageTables:      9382396 kB
Line 1641: PageTables:     10236492 kB

8. 既然问题找到了，如何解决呢？

Hugepages是解决这种问题的最好方案。

hugepages的内存块是2M（普通内存块是4K），首先内存管理的成本就降低500倍，而且hugepages的内存表是可以共享的。

9. 最终，配置hugepages，解决问题。

相关hugepages文档，请参考另两篇blog

Hugepages你用了吗？----原理概念篇

Hugepages你用了吗？----测试案例篇

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

微信关注我们

原文链接：https://blog.51cto.com/hsbxxl/1900554

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

2分钟教你玩转Tengine编译安装部署

Tengine部分特性 nginx -m 查看所有已经加载的模块，static说明已经安装的，shared说明是动态安装的； nginx架构是模块化的，除了主模块，其他模块都需在安装时进行编译安装，也可在安装后进行编译安装； tengine完全兼容nginx的配置； tengine实现动态加载模块，不需重新编译，就可以实现安装新的模块。动态模块功能会被默认安装。而nginx不支持模块动态加载，需要编译重启；首先下载tengine-2.2.0.tar.gz；下载链接：http://pan.baidu.com/s/1jI7cycm密码：ig6x #安装编译所需环境： yumgroupinstall"developmentTools""ServerPlatformDevelopment"-y #安装编译所需的扩展模块： yum-yinstallzlib-develpcre-developenssl-devel #注释 zlib-devel扩展模块：支持压缩 pcre-devel扩展模块：支持url重写，pool扩展 openssl-devel扩展模块：支持https协议 #查看编译所支持的...

2017-02-23

712

一、启动Weblogic控制台，报错了，搜寻百度很多人有此类问题，但是搜了许久没有明确答案，这里博主则分析一下报错，结合谷歌和官网，今天探讨一下分析思路，解决并不难。 EnterusernametobootWebLogicserver:renzhiyuan#用户名 EnterpasswordtobootWebLogicserver:#密码 <2017-2-23下午03时09分47秒CST><Notice><WebLogicServer><BEA-000365><ServerstatechangedtoSTARTING.> <2017-2-23下午03时09分47秒CST><Info><WorkManager><BEA-002900><Initializingself-tuningthreadpool.> <2017-2-23下午03时09分48秒CST><Info><WorkManager><BEA-002942>&lt...

2017-02-24

1303

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。