Tasks #834
closed
Investigate heap usage via tcmalloc's extensions
Added by Greg Farnum about 13 years ago.
Updated about 13 years ago.
Description
tcmalloc has a lot of knobs we can fiddle with programmatically to get information out (and to change behavior). Implement them and see what they say about where our resident memory usage is coming from!
If it looks helpful, then we'll also want to look at actually adjusting behavior!
I've spent some time on this and so far I've gotten into situations where tcmalloc is keeping around a couple hundred MB extra which isn't currently in use by our system. That still leaves the majority of the unaccounted-for memory in a lot of tests, though... I also have some kernel memory output that I'd like to take a look at but am not too familiar with it, so I'll need to consult on that.
Still to do: see if calling ReleaseFreeMemory() periodically (or turning up tcmalloc's frequency of freeing) will do something to improve our resident RAM usage.
- Status changed from In Progress to Resolved
Ugh, so after entirely too much time looking at all kinds of things: tcmalloc had a lot of resident memory used up as part of its heap profiler. No idea why it was so much larger than both the heap and the heap output file, but there it is.
Problems with ptmalloc (which is what led to this damn time sink in the first place) were generally related to the previously-larger PG memory use, ptmalloc and the STL allocator being less efficient with our workloads than tcmalloc, and massif slowing things down so much that the OSDs couldn't keep up with their messages.
I have a few new hooks I set up (so not completely wasted time!) that I'm going to work into the profiler branch shortly.
Also available in: Atom
PDF