10:06 a.m.
Hi,
I'm Paolo, the main developer of the BFQ I/O scheduler.
The switch to the BFQ I/O scheduler by Fedora paves the way to up to a
~10X throughput boost, and up a ~400X latency reduction. This
performance improvement concerns I/O workloads generated by multiple
containers that share common storage devices. Actually it concerns,
in general, also workloads generated by multiple groups, VMs or
entities of any kind.
The reason for these apparently impressive numbers is that all other
solutions for controlling I/O severely underutilize the speed of
storage devices (usually between 10 and 20%).
If so, why probably you have never been warned about such an
impressive waste of resources? Because it is extremely difficult to
guarantee bandwidths and latencies on a loaded drive. So the most
common solution for avoiding starvation, or very high latencies, has
always been to keep storage devices underutilized. When an
underutilized device is hit by the I/O of some container/group/VM, it
is likely to serve this I/O very quickly, because it is unlikely to be
already busy serving other I/O. If the I/O demand grows, then one
simply adds more drives, so as to keep utilization low. And when this
stops scaling, one goes buy faster drives.
More clever solutions do exist. They are based on I/O throttling.
But, depending on the workload, these solutions may happen to forcibly
lower utilization to about the same values reached with the above
solution.
In contrast, BFQ is smart enough to highly utilize drives, with every
workload. So, using, e.g., only one drive, BFQ satisfies an I/O
demand that requires from 5 to 10 drives with the other solutions.
If you want to take advantage of this performance boost in Fedora
CoreOS, I'm willing to help in every step.
Thanks,
Paolo