Debiao 10 / 2.8.1 heap cache lead to OOM

27 views

Skip to first unread message

Chao Yang

unread,

Aug 15, 2022, 5:47:09 AM8/15/22

to gperftools

we make a project with lua(huge small objets in maps), and repalce the malloc system with gperftools 2.8.1

when the lua process running, i found the process will turn out OOM. Here's my stats

[2022-08-15 17:32:05.118] [info] [PHONESTCORE]
[malloc stats ------------------------------------------------
MALLOC: 72021680 ( 68.7 MiB) Bytes in use by application
MALLOC: + 7384039424 ( 7042.0 MiB) Bytes in page heap freelist
MALLOC: + 84018240 ( 80.1 MiB) Bytes in central cache freelist
MALLOC: + 11031808 ( 10.5 MiB) Bytes in transfer cache freelist
MALLOC: + 15552528 ( 14.8 MiB) Bytes in thread cache freelists
MALLOC: + 50593792 ( 48.2 MiB) Bytes in malloc metadata
MALLOC: ------------
MALLOC: = 7617257472 ( 7264.4 MiB) Actual memory used (physical + swap)
MALLOC: + 334692352 ( 319.2 MiB) Bytes released to OS (aka unmapped)
MALLOC: ------------
MALLOC: = 7951949824 ( 7583.6 MiB) Virtual address space used
MALLOC:
MALLOC: 36208 Spans in use
MALLOC: 14 Thread heaps in use
MALLOC: 8192 Tcmalloc page size

Call ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).
Bytes released to the OS take up virtual address space but no physical memory.
]

as above, i think maybe the heap cache got some leaks !

why the new span can not use the heap cache??

i read the source coke in page_heap.cc SearchFreeAndLargeLists

is there some bugs in it leading the result that we can not find the proper span in the free list?

i think we should iterate the free list two times, one only for the normal_free_list , if we don't have any, we then use the return_free_list, so we don't need to get more memory from os.( i am not sure, maybe the return_free_list cause the memory growing?)