一次”qmxdpls_subhea”内存耗尽的问题分析

版权声明:本文为Buddy Yuan原创文章,转载请注明出处。原文地址:一次”QMXDPLS_SUBHEA”内存耗尽的问题分析
一套RAC数据库其中的一个节点在17点05分左发生了重启。通过分析发现是内存耗尽导致了交换分区的使用,同时system cpu 100%导致的crash。首先观察2节点16点-16点30的awr报告,可以发现主机内存256GB,SGA使用了80GB,PGA使用了90GB左右。

从系统残余内存来看,仍然有256-80-90=76G可以用,而操作系统正常大概能占用50GB,应该还剩余26GB可用。但是问题就在于这个机器的大页设置不正确(当前设置为60GB)。导致一部分大页的内存是空闲没法使用的。

HugePages_Total: 31748
HugePages_Free: 5831
HugePages_Rsvd: 5828
HugePages_Surp: 0
Hugepagesize: 2048 kB

在从oswatch来看,8号11点还剩30GB内存,而到了9号11点则剩下16GB内存,到了下午的15点左右下降到了1.68GB。可见内存是持续缓慢的下降耗尽的。不是一个并发或者大的事务上来导致的。

zzz ***Sun Dec 8 11:00:03 CST 2019
MemTotal: 264410232 kB
MemFree: 31472452 kB

zzz ***Mon Dec 9 10:00:15 CST 2019
MemTotal: 264410232 kB
MemFree: 17231808 kB

zzz ***Mon Dec 9 16:00:19 CST 2019
MemTotal: 264410232 kB
MemFree: 1765052 kB

那么内存缓慢耗尽是什么原因呢?通过观察节点1没重启的进程情况,发现以下问题:

DEDICATED 7062 RM bea 405.396004 405383755 428595614 3145728 428595614
DEDICATED 7856 RM bea 431.021004 432892859 457824670 5505024 457824670
DEDICATED 13649 RM bea 491.771004 496860795 516807070 786432 516807070
DEDICATED 14834 RM bea 503.458504 509014107 531356062 3080192 531356062
DEDICATED 12960 RM bea 539.208504 548221595 570612126 4849664 570612126
DEDICATED 3089 RM bea 541.458504 548346875 572774814 4653056 572774814
DEDICATED 3619 RM bea 565.958504 575983915 599382430 5570560 599382430
DEDICATED 231 RM bea 666.458504 680193475 704633246 5439488 704633246
DEDICATED 21156 RM bea 703.333504 718921091 738646430 786432 738646430
DEDICATED 19747 RM bea 820.896004 839278371 861723038 589824 861723038

SQL> select sid,event,program,machine,sql_id,status from v$session where sid=19747;

SID EVENT PROGRAM MACHINE SQL_ID STATUS
---------- ------------------------------ ------------------------------------------------ ---------------------------------------- ------------- --------
19747 SQL*Net message from client JDBC Thin Client whrm_app6 INACTIVE

SQL> select sid,event,program,machine,sql_id,PREV_SQL_ID,status from v$session where sid=19747;

SID EVENT PROGRAM MACHINE SQL_ID PREV_SQL_ID STATUS
---------- ------------------------------ ------------------------------------------------ ---------------------------------------- ------------- ------------- --------
19747 SQL*Net message from client JDBC Thin Client whrm_app6 bunvx480ynf57 INACTIVE

SQL> select sid,event,program,machine,sql_id,PREV_SQL_ID,status from v$session where sid=21156;
SID EVENT PROGRAM MACHINE SQL_ID PREV_SQL_ID STATUS
---------- ------------------------------ ------------------------------------------------ ---------------------------------------- ------------- ------------- --------
21156 SQL*Net message from client JDBC Thin Client whrm_app8 bunvx480ynf57 INACTIVE

SQL> select sid,event,program,machine,sql_id,PREV_SQL_ID,status from v$session where sid=231;

SID EVENT PROGRAM MACHINE SQL_ID PREV_SQL_ID STATUS
---------- ------------------------------ ------------------------------------------------ ---------------------------------------- ------------- ------------- --------
231 SQL*Net message from client JDBC Thin Client whrm_app6 bunvx480ynf57 INACTIVE

可以看到相关进程占用的内存很高,已经是inactive了,但是内存并没发生回收。通过oradebug dump heapdump 命令dump其中的800MB的进程,发现进程分配了12000个extent,而这些extend中的chunk都是”qmxdpls_subhea“。

而关于这个内存区域的问题,通过mos搜索,可以发现出现大量的memory leak(内存泄露)的情况。

我们把这个情况反映给了应用人员,应用人员根据程序定位到是没关闭xmltype相关对象导致的内存泄露。对于XMLTYPE这类的操作,需要打开后执行free()进行关闭,释放内存。

参考文档:
Best Practises for XMLType Temporary LOB Usage (Doc ID 1955135.1)
How to Release Temporary LOB Segments without Closing the JDBC Connection (Doc ID 1384829.1)
分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *