Charles Lamb's Blog

[The following is a repost from on 1/31/06 on the Sleepycat blog.]

A JE user recently asked how many durable (the "D" in ACID) put() calls per second might be possible using JE. Since most of the time in a durable transaction is spent in the fsync(2)
call, the answer is largely dependent on the underlying disk drive
speed. I gave the user a small Java program that repeatedly writes and
fsync's (forces to disk) the same block of data and measures the number
of calls for a given time. Their results were interesting.

On
three different Win XP boxes with the same disk and CPU, the throughput
was 35, 37, and 42 write+fsync's/second. That's between 23 and 28 msec
per forced write. On another box running W2K Server (which for the sake
of this test is the same as W2K), the throughput was 637
write+fsync's/second, or 1.5 msec per write. So either the disk drive
on the W2K box was significantly faster (the drive is a Seagate
Barracuda, so that theory doesn't hold), or the write cache was enabled
and the writes were not actually being forced to disk.

The Sleepycat DB Reference Guide has a short write-up on disk caches.
While disk write caches certainly can improve database performance, if
you really want the D in ACID, you have to disable them. On-board read
caches are, of course, still OK and should generally help performance.

The
user's results correspond to what we have observed in our lab. Win XP
never uses the disk cache and Win 2K always uses the disk cache.
Further, I don't know of a way of switching either of those settings.
Solaris allows the administrator to enable or disable read and write
caches with the format command. The corresponding Linux command is hdparm(8).

All
of this is to say that if you want Durability for your transactions,
you need to make sure your disk and your operating system are not
faking you out. The best way to do it is to measure performance of
multiple write+fsync's and see if the numbers jive with the underlying
disk drives.