incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Coli <rc...@eventbrite.com>
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 <
dominique.devito@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

Mime
View raw message