Robert, Thanks for your explanation!
Regards, Dominique De : Robert Coli [mailto:rc...@eventbrite.com] Envoyé : vendredi 1 août 2014 19:50 À : user@cassandra.apache.org Objet : Re: question about commitlog segments and memlocking On Fri, Aug 1, 2014 at 2:53 AM, DE VITO Dominique <dominique.dev...@thalesgroup.com<mailto:dominique.dev...@thalesgroup.com>> wrote: The instruction « CLibrary.tryMlockall(); » is called at the very beginning of the setup() Cassandra method. So, the heap space is memlocked in memory (if OS rights are set). “mlockall()” is called with “MCL_CURRENT” : “MCL_CURRENT Lock all pages currently mapped into the process's address space.” So, AFAIU(nderstand), the commitlog segments (or other off-heap structures) are NOT memlocked, and may be swapped. Is it also your understanding ? If true, why not using “mlockall(MCL_FUTURE)” instead, or calling mlocka() after commitlog segments allocation ? The intent of the memlock patch at the time it was contributed was to ensure that stuff in the heap was memlocked, because Cassandra didn't do much off-heap allocation at the time. Your understanding is correct that off-heap allocation generally is not memlocked, though I'm not sure if this is on purpose or not. I have personally had some concern regarding the swapping of off-heap memory structures in Cassandra, though best practice is to run Cassandra on nodes without swap defined. In trunk, there is a bit more reporting of off-heap allocation, so at least you can monitor it via JMX. That said, your question is really more appropriate for the cassandra-dev mailing list. Someone who actually knows if there's a rationale for this decision may or may not reply here. :) =Rob
