Hacker News Reader

Comment by adrian_b | Hacker News Reader

Yes, and in the following messages the conclusion was that the regression is mitigated when using huge pages.

This seems bad, Splunk advises you to turn off THP due its small read/write characteristics: https://help.splunk.com/en/splunk-enterprise/release-notes-a...

Bad because as of Splunk 10.x, Splunk bundles postgres to integrate with their SOAR platform. Parenthetically, this practice of bundling stuff with Splunk is making vuln remediation a real pain. Splunk bundles its own python, mongod, and now postgres, instead of doing dependency checking. They're going to have to keep doing it as long as they release a .tgz and not just an RPM. The most recent postgres vuln is not fixed in Splunk.

Huge pages and THP are not the same thing.

Which you always should use anyway if you can.

Hmmm, it's not always that clear cut.

For example, Redis officially advised people to disable it due to a latency impact:

https://redis.io/docs/latest/operate/oss_and_stack/managemen...

Pretty sure Redis even outputs a warning to the logs upon startup when it detects hugepages are enabled.

Note that I'm not a Redis expert, I just remember this from when I ran it as a dependency for other software I was using.

1) That is about transparent huge pages which is a different thing and 2) it is always clear cut for PostgreSQL. If you can you should always use huge pages (the non-transparent kind).

That's transparent huge pages, which are also not the setting recommended for PostgreSQL.

Java can work with transparent hugepages (in addition to preallocated hugepages), but you just use +AlwaysPreTouch to map them in during the startup so that at runtime there won't be any delays or jitter. Redis should add a similar option

Reply on news.ycombinator.com