We recently figured out that mlockall is not working for us. Unfortunately,
even with setting common.jna logging level to debug, no message was getting
printed out indicating this (it really would be nice to have a definitive
yes/no mlockall worked in the logs).
For the moment, instead of locking the elasticsearch JVM heap in memory,
we've set the vm.swappiness level to 0. Setting the swappiness level to 0
does effect all processes, not just elasticsearch, but these machines are
single purpose search boxes, so I doubt that will be a problem.
Anybody know if there any tradeoffs between the mlockall and vm.swappiness
for dedicated search boxes?
Others can address the mlockall part, but I'll say that I set swappiness to
0 on servers as soon as I get my hands on them and have never regretted it,
but seen only positives - no swapping.
Otis
Solr & Elasticsearch Support
On Monday, January 14, 2013 2:19:59 PM UTC-5, ppearcy wrote:
We recently figured out that mlockall is not working for us.
Unfortunately, even with setting common.jna logging level to debug, no
message was getting printed out indicating this (it really would be nice to
have a definitive yes/no mlockall worked in the logs).
For the moment, instead of locking the elasticsearch JVM heap in memory,
we've set the vm.swappiness level to 0. Setting the swappiness level to 0
does effect all processes, not just elasticsearch, but these machines are
single purpose search boxes, so I doubt that will be a problem.
Anybody know if there any tradeoffs between the mlockall and vm.swappiness
for dedicated search boxes?
On Monday, January 14, 2013 9:21:13 PM UTC-7, Otis Gospodnetic wrote:
Others can address the mlockall part, but I'll say that I set swappiness
to 0 on servers as soon as I get my hands on them and have never regretted
it, but seen only positives - no swapping.
On Monday, January 14, 2013 2:19:59 PM UTC-5, ppearcy wrote:
We recently figured out that mlockall is not working for us.
Unfortunately, even with setting common.jna logging level to debug, no
message was getting printed out indicating this (it really would be nice to
have a definitive yes/no mlockall worked in the logs).
For the moment, instead of locking the elasticsearch JVM heap in memory,
we've set the vm.swappiness level to 0. Setting the swappiness level to 0
does effect all processes, not just elasticsearch, but these machines are
single purpose search boxes, so I doubt that will be a problem.
Anybody know if there any tradeoffs between the mlockall and
vm.swappiness for dedicated search boxes?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.