4 ms·

> 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 ar

> 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.

deadbeeves 3y ago
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.
- ignoramous 3y ago
  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://brooker.co.za/blog/2021/05/24/metastable.html / https://archive.is/6Qtet https://archive.is/6Qtet
mlyle 3y ago
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?
newaccount74 3y ago
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.
arghwhat 3y ago
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.

deadbeeves 3y ago

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.

ignoramous 3y ago
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://brooker.co.za/blog/2021/05/24/metastable.html / https://archive.is/6Qtet https://archive.is/6Qtet

mlyle 3y ago

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?

newaccount74 3y ago

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.

arghwhat 3y ago

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.