Hacker News Reader

Comment by wiremine | Hacker News Reader

Spun one up and ran some quick numbers on a 100GB volume:

root@ubuntu-1gb-nyc1-01:~# time dd if=/dev/disk/by-id/scsi-0DO_Volume_volume-nyc1-01 of=test.dat bs=1024 count=10000000 10000000+0 records in

10000000+0 records out

10240000000 bytes (10 GB) copied, 58.0655 s, 176 MB/s

real 0m58.248s

user 0m2.608s

sys 0m41.604s

Some quick observations:

* Easy to add one when creating a droplet; by default they let you create volumes with these sizes: 100GB, 250GB, 500GB, 1000GB, 1.95TB; it's also really easy to create your own size.

* You can resize in any increments; took about 4 seconds to go from 100GB to 110GB with no downtime; you obviously need to resize/manage the mounted volume yourself.

* [Edit 1] Deleting the droplet does NOT destroy the volume. Worth keeping in mind when you spin them up/down.

* [Edit 2] Remounting an existing volume to a new droplet was quick and painless.

View on HN

Thank you for telling us these details.

I can't help but I note that you benchmark the drive with a block size of 1024. Minimum block size of a modern SSD is 4096, anything lower would just cause unnecessary load. Also if you want to benchmark a drive/block storage I highly recommend using fio.

Thx for the tip, I'll give that a try!

    fio --direct=1 --rw=write --ioengine=libaio --runtime=300 --bs=4k --numjobs=4 --iodepth=32 --size=2G --name=4096-direct --filename=/dev/vdb --group_reporting

This is my "dd" test for any storage system. Filename can be a regular file; you can also pass --directory instead. I would love to see numbers for both this test as well as with --bs=4M.

Also experiment with --rw=rw|randrw|read :)

(and make sure your device is large enough to hold numjobs*size)

Don't use dd for those tests it's really bad, especially on VMs.

What do you mean by "really bad", out of interest?

I should rephrase that, it's not "really bad" but the way that most people use it is not good. The main issue is caching from your OS, and caching from the hypervisor ( the one that runs your VM ).

There is also the problem about i/o syncing. By default OS buffer the data before writing it to disk.

That's true of all I/O benchmarks, even those which try to do things like call fsync since the lower layers often lie about whether something was committed to durable storage. The only way to do benchmarks reliably is still to make sure that you're reading/writing data which is much larger than the available cache.

In the case of dd, the real reason why it's often a misleading benchmark is that it's the best-case scenario: full-size streaming I/O where each block is only accessed once. Some applications do have that kind of operations pattern but most don't and can see very different performance characteristics because they depend on things like file creation/deletion overhead, random I/O within an open file, read and write contention if the same file is being accessed by multiple processes, etc.

probably because it can produce meaningless results. it's extremely hard to tell where which bits actually ended up, ram, or disk, or some other intermediate buffer or cache on a controller somewhere.

we use fio with a standard test config across systems for meaningful results.

What should be used for I/O throughput tests instead?

I usually use Bonnie++ when testing disk performance. http://www.coker.com.au/bonnie++/

The only thing worse than dd is bonnie++. Please, folks, use fio, or at least iozone, with multiple threads and/or a queue depth greater than one.

Are you sure? Bonnie++ has byte-wise and block-wise tests. Yes, the byte-wise tests are CPU bound (as expected), but I have not seen that for the block-wise tests on any machine so far?

Bonnie++ is heavily CPU limited and should not be used for disk benchmarking

fio or bonnie++. I've used fio with PerfKitBenchmarker in the past for some cross cloud platform comparisons.

One key thing is doing active benchmarking to validate what you're testing. See an example at http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html

Reply on news.ycombinator.com