From 09359c21cfe2d0f19420037dcbfc425ff58cfe66 Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Sat, 29 Jul 2023 16:07:33 -0400 Subject: [PATCH] Fix wording in random write --- content/pvc-ceph-tuning-adventures-part-3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pvc-ceph-tuning-adventures-part-3.md b/content/pvc-ceph-tuning-adventures-part-3.md index 1edc9b1..f06c241 100644 --- a/content/pvc-ceph-tuning-adventures-part-3.md +++ b/content/pvc-ceph-tuning-adventures-part-3.md @@ -129,7 +129,7 @@ System load continues to show almost no correlation at all with performance, and Random writes bring back the strange anomaly that we saw with sequential reads in the previous post. Namely, that for some reason, the no-limit configuration performs significantly better than all limits. After that, the performance seems to scale roughly linearly with each increase in CPU core count, exactly as was seen with the SATA SSDs in the previous post. -The system load here shows a possibly explanation for the anomalous results though. Random writes seem to hit the CPU much harder than the other tests, and the baseline load of all nodes with the no-limit configuration is about 8, which would indicate that the OSD processes want about 8 CPU cores per OSD here. This is double even our highest limited configuration, and thus seems to indicate that any OSD CPU limit below 4+8+20 will hurt write performance. Adding in the 4+8+20 configuration, we can see that this is definitely higher than all the other limit configurations, but is still less than the no-limit configuration. +The system load here shows a possibly explanation for the anomalous results though. Random writes seem to hit the CPU much harder than the other tests, and the baseline load of all nodes with the no-limit configuration is about 8, which would indicate that the OSD processes want about 8 CPU cores per OSD here. Adding in the 4+8+20 configuration, we can see that this is definitely higher than all the other limit configurations, but is still less than the no-limit configuration. It does appear that the scaling is not linear as well, since doubling the cores only brought us about half-way up to the no-limit performance, thus giving us a pretty conclusively "yes" answer to our first main question. For write-heavy workloads, this is a very important takeaway. This test clearly shows that the no-limit configuration is ideal for random writes on NVMe drives, as the Linux scheduler seems better able to distribute the load among many cores. I'd be interested to see how this is affected by many CPU-heavy noisy-neighbour VMs, but testing this is extremely difficult and thus is not in scope for this series.