On Wed, Apr 29, 2015 at 11:15 PM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote: > Hmm, I think we need to pay a lot attention to this problem especially > for fast storage device backend. > > I think the way to solve this problem rely to ceph itself instead of > tcmalloc or jemalloc optimization. > > I'm not sure the most consuming memory is used by which part, > frequently-used object like ObjectContext/OpTracker or buffers in > bufferlist. We've talked very briefly about using pools for ObjectContext and OpTracker objects which might help, but the bulk of the memory allocation is usually going to be for the message bufferlists, which are variable-length. :( (Strictly speaking so are a lot of the others which include string renditions of the object name, but that can be worked around at least a bit more than the actual message contents can.) > Could tcmalloc or jemalloc provide with malloc/free usage > statistic infos which contain callstack, so we may see the memory > bottleneck from it? You can do this with tcmalloc, and it's even integrated into Ceph with the various heap commands. :) > > On the other hand, maybe ceph need to consider to do memory management > itself for the main or frequent memory users. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
