Hacker News Reader

Comment by antirez | Hacker News Reader

I do not agree much with this conclusion. If you can't measure very well, the safe bet is to disable THP because they are capable of improving of a given percentage the performance on certain use cases, but can totally destroy other use cases. So when there is not enough information the potential gain/lose ratio is terrible... So I would say "blindly disable THP", unless you can really go to use-case-specific costly measurement activities and are able to prove yourself that in your use case THP are beneficial.

View on HN

It's much worse than that though because this isn't a case of measure throughput with, then without and see which is best. Rather, your application is sailing toward a submerged iceberg that when it hits (could be next week) will stall your process, and potentially the entire box, for 60 seconds.

And it doesn't print a message like "yeah I stalled your box for the last 60 seconds in order to shuffle deckchairs around, sorry" in syslog.

So you pull your hair out trying to figure out why your nice stable service all of a sudden sets off Nagios at 2am for no obvious reason, every week or two.

As a counterpoint, consider that random recommendations from the internet can easily get outdated.

So apparently, transparent hugepages have some issues in their current implementation that can cause big performance losses in some cases. Seems to me like that's a bug, and I see no reason why that bug couldn't be fixed in the future.

By following random recommendations, you get into situations where the underlying problem has been fixed for ages, but people still cargo-cult some workaround that actually makes things worse with the new implementation.

If you can't measure (very well?), how would you know the improvement in a certain use-case exists or not?

Indeed. If you can't really measure the difference, then I'd say setting it either way probably doesn't matter anyway.

More like : if you can't measure the difference then definitely turn it off because if it is on there is a non-zero chance of significant instability events in your future.

If I'm understanding their comments correctly it's because the downside isn't just a possible not-increase/decrease in performance it's instability and unpredictable behavior. I worry that it could translate into those vague and difficult to reproduce "the application is weird/slow" reports.

Of course you could profile and measure performance to determine if the warning is applicable but is that something I should be doing for every part of the stack? I should but should I prioritize that over x, y or z?

If you apply this same reasoning consistently to every other performance optimization i doubt you'll be left with a quick computer.

"Don't change any defaults unless you can do extensive use-case-specific measurements" is probably the best way to keep a computer quick, I would say.

Quick! Download that registry cleaner that promises you to get your machine up to lightning speed!

I would also say the same if you host a Ruby or Python app, or anything using forking really.

Similar to the issues you had with Redis, the kernel change to THP on by default totally destroyed CoW sharing for forked Ruby processes, despite Koichi Sasada's change to make the GC more CoW friendly. Without disabling THP, a single run of GC marking can cause the entire heap to be copied for the child.

i feel the same, you should only use these kind of performance improvements if you MUST, not just to gain speed willynilly. Speed always comes at a price, and if it's not needed , then it;'s not needed. Faster is not always better!

Reply on news.ycombinator.com