incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DE VITO Dominique <dominique.dev...@thalesgroup.com>
Subject RE: question about commitlog segments and memlocking
Date Mon, 04 Aug 2014 11:43:46 GMT
Robert,

Thanks for your explanation!

Regards,
Dominique

De : Robert Coli [mailto:rcoli@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.devito@thalesgroup.com<mailto: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