# OS setting "transparent huge pages"

**URL:** <https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628>\
**Category:** Elasticsearch\
**Created:** [May 13, 2015, 2:34pm UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628 "2015-05-13T14:34:01Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Suny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/suny/32/22082_2.png) [@Suny](https://discuss.elastic.co/u/Suny)\
**Post date:** [May 13, 2015, 2:34pm UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/1 "2015-05-13T14:34:01Z")

</div>

Hi.  
I've come across the transparent\_hugepage setting which is enabled by default in newer Linux distributions. It hurts all kinds of databases, Redis, Oracle, TokuDB, and this is no surprise as RedHat says that "THP is not recommended for database workloads". What is your experience with this setting and elasticsearch, and what do you recommend?  
You can check it with  
cat /sys/kernel/mm/transparent\_hugepage/enabled  
always [madvise] never  
I plan to change it to "never".

---

<div class="post-metadata">

**Author:** ![mikemccand](https://avatars.discourse-cdn.com/v4/letter/m/f04885/32.png) [@mikemccand](https://discuss.elastic.co/u/mikemccand)\
**Post date:** [May 13, 2015, 8:36pm UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/2 "2015-05-13T20:36:50Z")

</div>

In my limited data point (Lucene nightly benchmarks at [http://people.apache.org/~mikemccand/lucenebench/indexing.html;](http://people.apache.org/~mikemccand/lucenebench/indexing.html;) see annotations AV and AW), leaving THP enabled gives faster indexing throughput than disabling it.

I never did a more thorough test ... and it could be if I had enabled explicit huge pages in the OS and JVM (rather than letting it be "transparent") that performance would have been even higher than THP.

So be careful because my experience was the opposite ...

---

<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:** [May 13, 2015, 10:25pm UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/3 "2015-05-13T22:25:49Z")

</div>

If you set JVM heap with `-Xms` and `-Xmx`, which is managed by ES\_HEAP\_SIZE, ES allocates heap at start time at once, and does not try to release it back to the OS while running. With `mlockall` enabled, ES process memory are not exposed to swap. Hence, there is not much communication between Linux kernel and ES JVM process about memory allocation and release. New Linux kernels do not trust JVM processes when they demand for large memory and allocate memory pages lazily until a page is touched. If you want to convince the Linux kernel about the memory demand of the ES process, add `-XX:+AlwaysPreTouch` to the JVM options.

THP peculiarities are caused by a strange effect when huge memory pages are beginning to swap when the Linux kernel assumes the JVM process does not need all the memory pages and starts to move them around. With the above settings, the chance is rare this can really happen to ES.

So for the majority of cases (note, beside ES, there should be no other large application running on the same host), you can ignore THP being enabled.

---

<div class="post-metadata">

**Author:** ![Suny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/suny/32/22082_2.png) [@Suny](https://discuss.elastic.co/u/Suny)\
**Post date:** [May 15, 2015, 9:08am UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/4 "2015-05-15T09:08:44Z")

</div>

Thanks for sharing these benchmarks, it's a great help. I will be very careful, now.

---

<div class="post-metadata">

**Author:** ![Suny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/suny/32/22082_2.png) [@Suny](https://discuss.elastic.co/u/Suny)\
**Post date:** [May 15, 2015, 9:10am UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/5 "2015-05-15T09:10:58Z")

</div>

From what I've read, THP effects performance even without swapping.

---

<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:** [May 17, 2015, 8:34am UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/6 "2015-05-17T08:34:07Z")

</div>

You can check this in `cat /proc/vmstat`

If the number in `thp_split` and `thp_collapse_alloc` correlates with `pgscan_direct_normal` you might have a THP-related problem. If `thp_split` and `thp_collapse_alloc` is small in comparison to `pgscan_direct_normal` there is no reason to be concerned.

---

<div class="post-metadata">

**Author:** ![Suny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/suny/32/22082_2.png) [@Suny](https://discuss.elastic.co/u/Suny)\
**Post date:** [May 18, 2015, 1:15pm UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/7 "2015-05-18T13:15:16Z")

</div>

Thanks. I checked, and on the busy machines we have a ratio of pgscan\_direct\_normal:thp\_collapse\_alloc of 1:1000. I'll tell you my results when I'm done with my testing.

---

<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:** [July 6, 2017, 12:13am UTC](https://discuss.elastic.co/t/os-setting-transparent-huge-pages/628/8 "2017-07-06T00:13:31Z")

</div>


