Vijay Bellur <vbel...@redhat.com> wrote: > 6. Noticing those allocations which have significant size & num_allocs > in the output of grep can help in narrowing down the leak.
Here are the worst offenders for num_allocs: [protocol/server.gfs35b4-server - usage-type 48 memusage] size=17344060 num_allocs=408214 max_size=17344112 max_num_allocs=408214 total_allocs=621264 [protocol/server.gfs35b4-server - usage-type 45 memusage] size=5236270 num_allocs=219576 max_size=5238059 max_num_allocs=219577 total_allocs=476119 [protocol/server.gfs35b4-server - usage-type 38 memusage] size=635362 num_allocs=219566 max_size=635362 max_num_allocs=219566 total_allocs=275956 [features/access-control.gfs35b4-access-control - usage-type 48 memusage] size=3496124 num_allocs=87377 max_size=3496124 max_num_allocs=87377 total_allocs=87377 [features/access-control.gfs35b4-access-control - usage-type 39 memusage] size=93236 num_allocs=46618 max_size=93236 max_num_allocs=46618 total_allocs=46618 [features/access-control.gfs35b4-access-control - usage-type 45 memusage] size=1142043 num_allocs=46614 max_size=1142043 max_num_allocs=46614 total_allocs=46614 I also have this with big size: [global.glusterfs - usage-type 49 memusage] size=9711104 num_allocs=9 max_size=9711104 max_num_allocs=9 total_allocs=9 [protocol/server.gfs35b4-server - usage-type 49 memusage] size=5525504 num_allocs=4 max_size=5525504 max_num_allocs=4 total_allocs=4 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
