An update: it appears that this is not a memory leak, but a consequence of the way the Java 6 VM GC works combined with the NIO buffering system.
Using "jmap -histo:live" was the way to go: it showed a fairly constant size after a while because it seems to force a general GC, whereas the "-histo" option doesn't, and thus showed the steady increase in buffers that I was seeing. That, combined with using a large heap size (-Xms64M -Xmx256M), was triggering the excessive memory usage. I can only assume the Java 6 GC strategy avoids calling GC at all if it's nowhere near it's max heap size, because forcing a GC would usually shed 20-30M off the RSS. So, I estimated actual heap usage by watching the production server with "jmap -heap", and reduced the allocated heap to "-Xms12M -Xmx96M" (which is still erring on the large side), at which point RSS levelled out at ~40M, with ~1MB of buffers. Thanks for your help. Hopefully this will be of use to anyone else who runs into this sort of behaviour and mis-diagnoses it. Matthew. -- View this message in context: http://www.nabble.com/Memory-leak-in-MINA-1.1.4-tf4849077s16868.html#a14012900 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
