# Mlockall and mmapfs store type clarification **URL:** \ **Category:** Elasticsearch\ **Created:** [August 6, 2013, 9:19pm UTC](https://discuss.elastic.co/t/mlockall-and-mmapfs-store-type-clarification/13095 "2013-08-06T21:19:14Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Tinou\_Bao](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tinou_bao/32/1736_2.png) [@Tinou\_Bao](https://discuss.elastic.co/u/Tinou_Bao)\ **Post date:** [August 6, 2013, 9:19pm UTC](https://discuss.elastic.co/t/mlockall-and-mmapfs-store-type-clarification/13095/1 "2013-08-06T21:19:14Z")
Hi, I understand that if bootstrap.mlockall is true then mlockall is called to lock the process virtual memory to avoid swapping. The question/clarification is: Does the mlockall then apply to memory-mapped file (mmapfs) indexes? Or is the mlockall only applicable to the elasticsearch process, not any of the mmapfs indexes. Example: If I start elasticsearch and it mlockall 4GB of memory, then I have an mmapfs index that grows to 20GB, will it try to mlockall the additional 20 GB mmapfs index? I think the answer is mlockall only applies to the elasticsearch process, not the mmapfs indexes. From the code\* \*it looks like mlockall is being called w/ the MCL\_CURRENT flag so only the current virtual memory. Any help is appreciated, Thanks Tinou -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 6, 2013, 11:35pm UTC](https://discuss.elastic.co/t/mlockall-and-mmapfs-store-type-clarification/13095/2 "2013-08-06T23:35:32Z")
There are two mechanisms, mlockall and mmap, so I'd like to explain what they do. First, mlockall, when called via JNA with the MCL\_CURRENT flag, enforces the OS to keep the JVM process pages in RAM. mlockall is invoked at a very early stage during Elasticsearch bootstrap [0] (therefore bootstrap.mlockall). With MCL\_CURRENT, the invocation does affect only one OS call. It means, no further malloc()ed memory segments of the JVM process will be locked. MCL\_FUTURE would force each future malloc call of the process (and forked processes) to get included into the locking. This is out of control of the JVM, and is prone to segfaults (core dumps). With having allocated the heap size with -Xms and -Xmx like in ES\_HEAP\_SIZE, the JVM will not perform malloc() again for the heap. The result is that heap-based operations of Elasticsearch are executed in RAM for the lifetime of the process. mlockall is only available on POSIX OSes. Elasticsearch mmapfs (memory mapped store implementation) is based on Lucene's MMAPDirectory. The memory mapping of Lucene in MMAPDirectory [1] uses ByteBuffer allocations, executed by malloc() calls, which are then changed with the mmap() call to inform the OS that file reads on Lucene index files should be treated directly in the virtual memory address space. So, this mechanism relates to the input/output subsystem of the OS, it maps the device I/O buffer directly into the process address space. Such mapped files prevent double copying of I/O buffered data while reading. When Lucene files are written, the ordinary OS file caching is used. mmap is available on every modern 64-bit OS. Additionally, Lucene's MMAPDirectory can unmap the ByteBuffers by a hack because Java does not support this by default [2]. ByteBuffers for large files use a lot of virtual address space, so it is recommend only on 64-bit platforms. But there is a problem when Lucene wants to close files and switch over to new files. ByteBuffers are maintained by a weak reference, they are only disposed by the garbage collector when no thread is using the buffer anymore. The risk of getting OOMs will get higher the more index files Lucene reads from. To tackle this, Lucene enforces the disposition of the virtual memory address space by an unmap() hack using not well documented code. In summary, the MCL\_CURRENT flag is useful so ByteBuffers don't get locked but mapped for I/O properly. Still both mlockall/mmap share the same target: making optimal use of RAM for Elasticsearch. Jörg [0] [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/bootstrap/Bootstrap.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/bootstrap/Bootstrap.java) [1] [http://svn.apache.org/repos/asf/lucene/dev/tags/lucene\_solr\_4\_4\_0/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java](http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_4_0/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java) [2] [http://bugs.sun.com/view\_bug.do?bug\_id=4724038](http://bugs.sun.com/view_bug.do?bug_id=4724038) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:22am UTC](https://discuss.elastic.co/t/mlockall-and-mmapfs-store-type-clarification/13095/3 "2017-07-06T02:22:33Z")