Repository files navigation

Benchmark Kubernetes persistent disk volumes withfio: Read/write IOPS, bandwidth MB/s and latency.

1. Downloaddbench.yaml and edit thestorageClassName to match your Kubernetes provider's Storage Classkubectl get storageclasses
2. Deploy Dbench using:kubectl apply -f dbench.yaml
3. Once deployed, the Dbench Job will:
   • provision a Persistent Volume of1000Gi (default) usingstorageClassName: ssd (default)
   • run a series offio tests on the newly provisioned disk
   • currently there are 9 tests, 15s per test - total runtime is ~2.5 minutes
4. Follow benchmarking progress using:kubectl logs -f job/dbench (empty output means the Job not yet created, orstorageClassName is invalid, see Troubleshooting below)
5. 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/sAverage Latency (usec) Read/Write: 183.07/76.91Sequential Read/Write: 536MiB/s / 512MiB/sMixed Random Read/Write IOPS: 43.1k/14.4k

6. 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 usingkubectl 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 a4000Gi 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 allfio tests are indocker-entrypoint.sh.

• Lee Liu (LogDNA)
• Alexis Turpin

• MIT