Benchmark Kubernetes persistent disk volumes with fio
: Read/write IOPS, bandwidth MB/s and latency.
- Download dbench.yaml and edit the
storageClassName
to match your Kubernetes provider's Storage Classkubectl get storageclasses
- Deploy Dbench using:
kubectl apply -f dbench.yaml
- Once deployed, the Dbench Job will:
- provision a Persistent Volume of
1000Gi
(default) usingstorageClassName: ssd
(default) - run a series of
fio
tests on the newly provisioned disk - currently there are 9 tests, 15s per test - total runtime is ~2.5 minutes
- provision a Persistent Volume of
- Follow benchmarking progress using:
kubectl logs -f job/dbench
(empty output means the Job not yet created, orstorageClassName
is invalid, see Troubleshooting below) - At the end of all tests, you'll see a summary that looks similar to this:
==================
= Dbench Summary =
==================
Random Read/Write IOPS: 75.7k/59.7k. BW: 523MiB/s / 500MiB/s
Average Latency (usec) Read/Write: 183.07/76.91
Sequential Read/Write: 536MiB/s / 512MiB/s
Mixed Random Read/Write IOPS: 43.1k/14.4k
- Once the tests are finished, clean up using:
kubectl delete -f dbench.yaml
and that should deprovision the persistent disk and delete it to minimize storage billing.
- If the Persistent Volume Claim is stuck on Pending, it's likely you didn't specify a valid Storage Class. Double check using
kubectl get storageclasses
. Also check that the volume size of1000Gi
(default) is available for provisioning. - It can take some time for a Persistent Volume to be Bound and the Kubernetes Dashboard UI will show the Dbench Job as red until the volume is finished provisioning.
- It's useful to test multiple disk sizes as most cloud providers price IOPS per GB provisioned. So a
4000Gi
volume will perform better than a1000Gi
volume. Just edit the yaml,kubectl delete -f dbench.yaml
and runkubectl apply -f dbench.yaml
again after deprovision/delete completes. - A list of all
fio
tests are in docker-entrypoint.sh.
- Lee Liu (LogDNA)
- MIT