案例:troubleshooting ORA-04031 in “gcs dynamic shadows lms” on 19c

某客户环境rac 19.3出现大量ORA-04031报错,导致业务不能正常运行。

可以看到该trace在分配KGLH0(heap 0)时出现ORA-04031

报错显示sub heap KGLH0^c112cc58无法请求40 byte,所以报出了ORA-04031

查看报错subheap的信息

该subheap位于subpool 2,extent size为0xfe8(4076),Subheap has 0 bytes of memory allocated,说明还没有extent挂在subheap下面,此次分配是第一个extent。根据chunk的分配原则,首先尝试在子堆中分配,如果子堆free list无法分配则向父堆申请,这时申请的chunk大小将会是extent size,并作为一个新的extent挂在子堆下,由于是第一个extent,那么请求的大小肯定不是40 bytes,而是向parent heap请求4076 byte作为第一个extent。

parent heap堆描述符为0x601762a8,即sga heap。

此处可以看出该shared pool有7个subpool。由于报错出在subpool 2,所以看看subpool 2的内存占用情况以及free list

可以看到subpool 2 free list下面的bucket还有符合大小的chunk,为何没有分配呢?个人觉得此时的trace是报错之后生成的,很可能报错之后通过lru out了一些chunk,或者是shared pool  growth。从trace中发现,该session确实在等待sga growth。但是是否growth成功可以通过mman trace验证。

下面就应该去看看subpool 2的内存占用情况是否正常,是否有异常的组件占用了大量内存

可以很清晰的看到subpool 2的gcs dynamic shadows lms组件占用了32g内存,并且其他subpool都是正常的。这种多半是bug导致的。

查询mos文档发现匹配Bug 30223374 – Memory Leak Due to “gcs dynamic shadows lms” (Doc ID 30223374.8)

This fix has been superseded – please see the fixed version information for Bug:30318638 . The box below only shows versions where the code change/s for 30223374 are first included – those versions may not contain the later improved fix.

Fixed:

The fix for 30318638 is first included in

 

此条目发表在Oracle, Oracle troubleshooting分类目录,贴了, 标签。将固定链接加入收藏夹。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注