gperftools / gperftools/gperftools
Tcmalloc heap size is much less than the real memory size from the PS command
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 9k
- Forks
- 1.5k
- PR merge metrics
- No merged PRs in 30d
Description
Hi All,
I am using the tcmalloc(gperftools-2.2) on the redhat7.2 x86_64 VM(openstack), I face one issue during one test that the tcmalloc generic.heap_size of one process is around 19G bytes, but the physical memory size shown by the linux PS command(ps -e -orss=,args= | sort -b -k1,1n) is increasing continuously, 2G bytes are increased every hour, and now, 64G is being used. This process has 30 work threads, one thread does the incoming message distribution to the left threads, and it invokes MallocExtension::instance()->ReleaseFreeMemory() every 30s.
Did anyone face this issue before? Is this issue related to tcmalloc itself or caused by the application program? I didn't face this issue on redhat6.2 x86_64 before.
Thanks,
JC
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported discrepancy between tcmalloc's generic.heap_size and Linux ps RSS on the stated Red Hat 7.2 x86_64 environment. Examine behavior around MallocExtension::instance()->ReleaseFreeMemory() and the application's 30 worker threads; done means documenting whether the growth is allocator behavior or application-related, with evidence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- operating-systems, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100