# Virtual Memory Issue

**URL:** <https://discuss.elastic.co/t/virtual-memory-issue/78247>\
**Category:** Elasticsearch\
**Created:** [March 11, 2017, 3:36pm UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247 "2017-03-11T15:36:04Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![dashwood](https://avatars.discourse-cdn.com/v4/letter/d/a5b964/32.png) [@dashwood](https://discuss.elastic.co/u/dashwood)\
**Post date:** [March 11, 2017, 3:36pm UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/1 "2017-03-11T15:36:04Z")

</div>

I've locked the memory with mlockall, changed it in systemd but Elasticsearch, and set the memorylock in elasticsearch.yml Yet somehow still manages to allocate 145 GB of virtual memory. Out of our physical 32 GB of ram, we've allocated 27 GB of it to Elasticsearch alone via jvm.options using -Xmx and -Xms

I don't know what's causing it to allow virtual memory.

We have disabled swapping, we checked our drives and swap wasn't there anymore. We followed everything on the documentation as well.

When we do \_nodes?filter\_path=\*\*.mlockall it tells us mlockall is true.

Thank you in advance

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [March 11, 2017, 6:03pm UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/2 "2017-03-11T18:03:39Z")

</div>

mlockall just does the JVM heap, the virtual memory is handled by the OS.

---

<div class="post-metadata">

**Author:** ![dashwood](https://avatars.discourse-cdn.com/v4/letter/d/a5b964/32.png) [@dashwood](https://discuss.elastic.co/u/dashwood)\
**Post date:** [March 12, 2017, 3:08am UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/3 "2017-03-12T03:08:35Z")

</div>

Yes,

But the swap for the server is turned off.

---

<div class="post-metadata">

**Author:** ![Mohd\_Johari\_Othman](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@Mohd\_Johari\_Othman](https://discuss.elastic.co/u/Mohd_Johari_Othman)\
**Post date:** [March 12, 2017, 9:28am UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/4 "2017-03-12T09:28:52Z")

</div>

check this out

> **[Elasticsearch - Advanced settings and Tweaks](http://kufli.blogspot.my/2014/11/elasticsearch-advanced-settings-and.html?m=1)**
>
> Now that we have Elasticsearch installed and confirmed working, we can start looking into more advanced settings, more of tweaking, to impr...

---

<div class="post-metadata">

**Author:** ![dashwood](https://avatars.discourse-cdn.com/v4/letter/d/a5b964/32.png) [@dashwood](https://discuss.elastic.co/u/dashwood)\
**Post date:** [March 12, 2017, 12:22pm UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/5 "2017-03-12T12:22:19Z")

</div>

Hi,

I've read it over and ran

```
ulimit -l unlimited

```

and started elastic again and it's still using 145 GB of virtual memory.

Thank You

I also ran the mlock check again

```
root@server:~# curl -X GET "localhost:9200/_nodes?filter_path=**.mlockall&pretty"
{
  "nodes" : {
"ldx1RanBTyuE5FPKY660Dw" : {
  "process" : {
    "mlockall" : true
  }
}
  }
}

```

Picture of our processes through htop

[![](https://a.pomf.cat/ewhtyj.png) ](https://a.pomf.cat/ewhtyj.png)

---

<div class="post-metadata">

**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:** [March 12, 2017, 6:46pm UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/6 "2017-03-12T18:46:47Z")

</div>

The 145GB is not allocated, it's in column VIRT.

The column RSS of 27,5GB is allocated and locked.

You can ignore the 145 GB virtual memory, it's never used. Note that 64bit Linux has 16 Exabyte of virtual memory available. It's a side effect of Java 8 threads with Linux glibc malloc arenas, which is nothing much to worry about. Java 8 allocates metaspace and Linux reserves in advance more memory per thread for performance reasons, but in practice, it is not used at all.

Note, reserving 27GB of 32GB RAM (84%) to ES JVM heap is rather unusual and may have an impact on performance. This leaves only 5GB for the file system cache and other processes and is far from the recommended 50%.

---

<div class="post-metadata">

**Author:** ![dashwood](https://avatars.discourse-cdn.com/v4/letter/d/a5b964/32.png) [@dashwood](https://discuss.elastic.co/u/dashwood)\
**Post date:** [March 13, 2017, 1:42am UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/7 "2017-03-13T01:42:29Z")

</div>

For optimal performance what should the memory allocation be?

We are calculating about 3 billion records in total

---

<div class="post-metadata">

**Author:** ![rcowart](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rcowart/32/88091_2.png) [@rcowart](https://discuss.elastic.co/u/rcowart)\
**Post date:** [March 13, 2017, 5:39am UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/8 "2017-03-13T05:39:30Z")

</div>

Generally the recommendation is that the JVM heap should get 50% of physical memory, NOT to exceed 32GB. This leaves room for Lucene to use the OS file system cache. You can read more here... [Heap: Sizing and Swapping](https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html)

Rob

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 10, 2017, 5:39am UTC](https://discuss.elastic.co/t/virtual-memory-issue/78247/9 "2017-04-10T05:39:43Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
