https://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2011-02-27T21:01:46ZCeph Ceph - Tasks #834: Investigate heap usage via tcmalloc's extensionshttps://tracker.ceph.com/issues/834?journal_id=25252011-02-27T21:01:46ZGreg Farnumgfarnum@redhat.com
<ul></ul><p>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.</p>
<p>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.</p> Ceph - Tasks #834: Investigate heap usage via tcmalloc's extensionshttps://tracker.ceph.com/issues/834?journal_id=25462011-03-01T15:50:08ZGreg Farnumgfarnum@redhat.com
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>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.<br />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.</p>
<p>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.</p>