Hacker News new | ask | show | jobs
by fxtentacle 70 days ago
.. which confirms all of my stereotypes. Looks like the AWS engineer who reported it used a m8g.24xlarge instance with 384 GB of RAM, but somehow didn't know or care to enable huge pages. And once enabling them, the performance regression disappears.
1 comments

Because such settings aren’t obvious to those not familiar with them. LLMs should make discoverability easier though
Honest question: what's the value of running the benchmark and reporting a performance regression if the author is not familiar with basic operation of the software? I'd argue that not understanding those settings disqualifies you from making statements about it.
The performance was reduced without a settings change. That is still a regression even if huge pages mitigates the problem.

I'd be curious to know if there's still a regression with hugepages turned on in older kernels.

If you are benchmarking something and the only changed variable between benchmarks is the kernel, that is useful information. Even if your environment isn't correctly setup.

Some software clearly wants hugepages disabled, so it's not always the slam dunk people seem to be making it out to be.

ie Redis:

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

Yet we're talking about postgres, specifically. The whole point is that benchmarks about postgres better know how to configure postgres or their conclusions be irrelevant at best. What does redis have to do with this discussion?