Hacker News new | ask | show | jobs
Red Hat memory optimisations and Riak performance (underthehood.meltwater.com)
41 points by traxmaxx 4068 days ago
3 comments
jermo 4068 days ago
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-...

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.
link
geidies 4068 days ago
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... and why we set swappiness = 1.
link
mitchell_h 4068 days ago
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.

link
feld 4068 days ago
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...

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

link
bonzini 4067 days ago
THP was introduced for KVM, and has huge benefits there. In fact I suggest that you set /sys/kernel/mm/transparent_hugepage/enabled to "madvise" rather than "never". This was applications that like their hugepages can still enable it manually.
link
kokey 4068 days ago
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.
link