Why are disk writes so slow?

Oliver Fromme olli at lurza.secnetix.de
Wed Sep 27 07:02:34 PDT 2006


Mark Bucciarelli wrote:
 >                      1993       2006
 >                     -----       ----
 > (1) /dev/null write  0.3s       .005s  <-- read speed

If you mean to say that 1.5 MB have been read in 0.005s,
then that's certainly _not_ the read speed of your disk
drive.  No single drive currently in existence can deliver
300 MB per second.  Those 1.5 MB came from the cache.

 > (2) normal write     2.3s       .023s

Looks reasonable.

 > (3) O_SYNC          13.4s       .364s

Also looks reasonable.  Of course it depends a lot on the
type of disk (SCSI, ATA), interface speed (PIO*, UDMA*),
drive configuration (write caching etc.), vendor of disk
and controller, etc.

 > It does makes me wonder how this test runs on Linux, since I
 > think databases use O_SYNC.

Usually databases issue an fsync() call at important points
in time (e.g. after a full transaction was comitted).  The
performance is better than running all writes synchronously.

 > I guess I'd have to install Linux on
 > my laptop and run the same test to have any useful information.

What exactly do you try to find out?  Linux has different
file systems, different virtual memory management, different
buffer cache implementation, different scheduler, different
I/O drivers ...  The numbers that you'll get won't be very
useful for comparisons.

 > And reboot between each test.  And shut down network interface
 > and all daemons.

And don't read and write at the same time on the same drive
because the disk heads' seek times will blow the benchmark
up.  If you want to measure write speed, don't read from
the disk at the same time, and vice versa.  You should use
a disk which isn't used for anything else, i.e. don't use
the system disk for benchmarks.

If you want to benchmark the pure speed of the drive (not
the speed of the file system), then don't put a filesystem
on the disk at all.  Instead, use the raw device.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal


More information about the freebsd-performance mailing list