cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Coli <>
Subject Re: question about commitlog segments and memlocking
Date Fri, 01 Aug 2014 17:49:45 GMT
On Fri, Aug 1, 2014 at 2:53 AM, DE VITO Dominique <> 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

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. :)


View raw message