apr_memcache client memory usage

André Cruz andre.cruz at co.sapo.pt
Mon Oct 15 16:41:04 UTC 2007


Hello.

I'm having some memory related problems in a long running daemon that  
uses the apr_memcache client to talk to a memcache server. Basically  
the daemon uses up all the memory available in the machine after a  
few months of usage. :) Using valgrind I was able to pinpoint the  
guilty party which seems to be apr_memcache and it's use of the apr  
pools.

I normally create an apr pool which I pass to  
apr_memcache_server_create() and then create sub-pools each time i do  
a getp and destroy them afterwards. But it seems that with each get  
the main pool is used also and this pool I can't destroy on each  
iteration since I would have to create the server objects again.

This seems related to: http://issues.outoforder.cc/view.php?id=68

I attached a simple client that does a few gets and then just exits.  
Running this inside valgrind yields the following memory usage:

==31208== 983,040 bytes in 120 blocks are still reachable in loss  
record 3 of 3
==31208==    at 0x401C38B: malloc (vg_replace_malloc.c:149)
==31208==    by 0x403B961: apr_allocator_alloc (in /usr/lib/ 
libapr-1.so.0.2.7)
==31208==    by 0x40550CA: apr_bucket_alloc_create_ex  
(apr_buckets_alloc.c:87)
==31208==    by 0x405518C: apr_bucket_alloc_create  
(apr_buckets_alloc.c:73)
==31208==    by 0x40607FC: mc_conn_construct (apr_memcache.c:324)
==31208==    by 0x405E6AD: create_resource (apr_reslist.c:123)
==31208==    by 0x405E78A: reslist_maint (apr_reslist.c:181)
==31208==    by 0x405EBF8: apr_reslist_create (apr_reslist.c:271)
==31208==    by 0x40606B1: apr_memcache_server_create (apr_memcache.c: 
390)
==31208==    by 0x8048DD4: main (in /home/andre/test)

If I increase the number of iterations of the cycle this memory usage  
amount increases. Is there something wrong with my usage of the apr  
pools? Should I be doing something else that's missing? I even tried  
setting the free_max of the pool to "1" but that didn't change  
anything, I suspect the pool is really full of data.

Thanks for the help,
André Cruz


-------------- next part --------------
A non-text attachment was scrubbed...
Name: apr_memcache_test.cpp
Type: application/octet-stream
Size: 1266 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20071015/5431fe72/apr_memcache_test.obj


More information about the memcached mailing list