search

roc230 / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

Plausible Memory Leak Of Get Operations #159

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
While profiling the heap of our application that uses spymemcached, we observed 
what appeared to be a memory leak of the (binary) get operation objects (viz. 
net.spy.memcached.protocol.binary.GetOperationImpl.java). 

Specifically, when we looked at the output of "jmap -histo:live" <pid>", we saw 
millions of instances of the aforementioned class, when ideally, there should 
only be as many instances as the number of threads performing memcached gets 
(in our case, that would be around 300). 

In theory, the root cause could be any one of the following:
a) The MemcachedNode class does not clean up after itself, i.e., it does not 
take care to remove operations added to it, and/or,
b) The MemcachedNode class containing the operations are added to certain 
collections (maps and queues) but never removed from them.

Original issue reported on code.google.com by karthick...@gmail.com on 23 Dec 2010 at 2:49

GoogleCodeExporter commented 9 years ago 
This is interesting, but could you identify which JRE was in use?  Looking 
around, the -histo:live wasn't accurate in the 1.5 days.

See: 
http://www.java.net/forum/topic/performance/general-performance-discussion/jmap-
histo-0

The client is in wide use, and I would think a memory leak would have been 
identified before now.

Original comment by ingen...@gmail.com on 18 Feb 2011 at 6:45