Hacker News Reader

Comment by tanelpoder | Hacker News Reader

> You generally want to keep your CPU fully utilized.

Not in real life concurrent systems where latency matters. In addition to the queuing/random request arrival rate reasons, all kinds of funky latency hiccups start happening both at the DB and OS level when you run your CPU average utilization near 100%. Spinlocks, priority inversion, etc. Some bugs show up that don’t manifest when running with lower CPU utilization etc.

View on HN

This is a benchmark that tries to execute as many queries as possible, so the interesting stat is transactions per second, not CPU usage. This benchmark is testing top speed, not real world behaviour.

If you tested both systems with the same workload (eg. a specific number of queries per second), then the average CPU usage would be much lower for the more efficient engine.

The low CPU usage in this benchmark is just a sign that the performance is not CPU bound, but limited by other factors like locking or IO.

Here the system is doing a pretty consistent 750k TPS instead of oscillating between 0 and 225k-- often sitting near 0TPS for tens of seconds. Which system do you think will have better latency for any given loading?

So what you're saying is that an acceptable way to compensate the system's bugginess is by making it more inefficient? I'd rather use a system that's stable under load.

OP has a point [0], though I'm unsure if Kernels under load are really that unstable / untested.

[0] https://brooker.co.za/blog/2021/05/24/metastable.html / https://archive.is/6Qtet

A service should use 100% CPU when loaded fully, anything else means you are suffering from bottlenecks that are actively limiting your throughput. Having lower CPU load because your disks are barely hanging in there is certainly not better.

If you want lower max CPU load, just limit its resources (e.g., CPU quota, cpuset limitation) or load it less.

Reply on news.ycombinator.com