Block Storage Volume performance

June 14, 2019 413 views
Databases Ubuntu 18.04

We found out that XFS Block Storage Volume performance is quite low compared to the regular ext4 SSD disk bundled with droplets.

This is the hdparm result on a XFS Block Storage Volume:

root@db1:~# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 16970 MB in 1.99 seconds = 8514.97 MB/sec
Timing buffered disk reads: 532 MB in 3.00 seconds = 177.28 MB/sec

This is instead the hdparm result of bunlded SSD:

root@db1:~# hdparm -Tt /dev/vda1

/dev/vda1:
Timing cached reads: 16458 MB in 1.99 seconds = 8257.90 MB/sec
Timing buffered disk reads: 2798 MB in 3.00 seconds = 932.35 MB/sec

We’ve done those tests after we saw that some stress-test on API/DBs are running with low performance compared to other cloud providers.

Since we want to install and use a medium-sized MongoDB database (~25GB), XFS is a requirement, but putting MongoDB data on Block Storage is causing low performance compared to droplet’s bundled SSD disks.

We really love DO services but we also need to have fast SSD + XFS + MongoDB.
What can you suggest to avoid that low performance?

1 Answer

Hey there,

You will always see a bit worse performance on a Volume compared to local storage, Volumes are network-based storage which adds some overhead. In our experience, it is quite possible to run MongoDB databases on Volumes with proper tuning.

We recommend testing with MongoDB as the performance can differ from using hdparm which only writes/reads one file.

With regards to these results, that speed is expected on a Standard Droplet: https://www.digitalocean.com/docs/volumes/overview/#features

We recommend Optimized Droplets for higher burst throughput, but also recommend application tests to see how non-burst performance works for your use-case. The IOPs you get can be tuned by adjusting queue depth.

Queue depth is one of those things that we always like to bring up in regards to gaining improved performance with MongoDB on a Volume. Volumes in DO are tuned to perform at 5k iops, but that’s at a high queue depth and block sizes. At a lower QD (Queue Depth), we may see fewer IOPS as additional latency is introduced. Our Engineers have tested some benchmarks by manipulating the application’s QD. At a QD of ~2, we see about 500-600 iops. But, raising that to 32, he saw that raise to ~3400 iops. It is required to tune the application to work at a higher QD and tweak the settings to increase the number of parallel writes to the disk.

On the OS level, the following file ’/sys/block/<sdx>/device/queue_depth" stores the value of QD, and you’ll need to tune MongoDB’s QD and the OS QD together to get more performance. The following blog article MongoDB’s website details a bit about Queue Depth: https://www.mongodb.com/blog/post/performance-tuning-mongodb-on-solidfire. It’s suggested as well to discuss this with your DBA or Database administrator, if not MongoDB support for the best MongoDB tuning options.

Regards,
Ethan Fox
Developer Support Engineer II - DigitalOcean

Have another answer? Share your knowledge.