

Red Hat memory optimisations and Riak performance - traxmaxx
http://underthehood.meltwater.com/blog/2015/04/14/riak-elasticsearch-and-numad-walk-into-a-red-hat/

======
jermo
They're not the only ones running into issues with TPH and numa. For more
suggestions to reduce jitter on Linux see Gil Tene's (Azul) advice:
[http://highscalability.com/blog/2015/4/8/the-black-magic-
of-...](http://highscalability.com/blog/2015/4/8/the-black-magic-of-
systematically-reducing-linux-os-jitter.html)

Namely:

    
    
      - Turn THP (Transparent Huge Pages) OFF.
    
      - Set vm.min_free_kbytes to AT LEAST 1GB (8GB on larger systems).  
    
      - Set Swappiness to 0.  
    
      - Set zone_reclaim_mode to 0.

~~~
geidies
Good advise - but a swappiness = 0 setting can bite you as well. See an
explanation in [http://www.chinanetcloud.com/blog/attack-of-the-killer-
kerne...](http://www.chinanetcloud.com/blog/attack-of-the-killer-kernel-
change-swappiness) and why we set swappiness = 1.

------
mitchell_h
Has anyone actually run into a situation where THP is a benefit? I've run into
enough memory slow downs by transparent huge pages that it's just a default to
turn it off on all builds. I've never seen a production work load that has had
any performance gain from THP.

Same with numa.

~~~
feld
Yes, someone has been working on upstreaming 1GB SuperPages to FreeBSD because
it dramatically increased the performance of their firewall appliances.

[https://lists.freebsd.org/pipermail/freebsd-
hackers/2014-Nov...](https://lists.freebsd.org/pipermail/freebsd-
hackers/2014-November/046449.html)

These large (>4K) pages definitely have their uses.

------
kokey
It is also interesting to see a company using elasticsearch and riak together.
I have considered looking into that combination after having some grief with
riak 2.0 with a bundled in Solr.

