db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olav Sandstaa <Olav.Sands...@Sun.COM>
Subject Options for syncing of log to disk
Date Wed, 30 Aug 2006 09:06:59 GMT

For writing the transaction log to disk Derby uses a
RandomAccessFile. If it is supported by the JVM, the log files are
opened in "rws" mode making the file system take care of syncing
writes to disk. "rws" mode will ensure that both the data and the file
meta-data is updated for every write to the file. On most operating
system this leads to two write operation to the disk for every write
issued by Derby. This is limiting the throughput of update intensive
applications.

I have run some simple tests where I have changed mode from "rws" to
"rwd" for the Derby log file. When running a small numbers of
concurrent client threads the throughput is almost doubled and the
response time is almost halved. I am enclosing two graphs that show
this when running a given number of concurrent "tpc-b" clients. The
graphs show the throughput when running with "rws" and "rwd" mode when the
disk's write cache has been enabled and disabled.

This change should also have a positive impact on the Derby startup
time (DERBY-1664) and derbyall. With this change the time for running
derbyall goes down by about 10-15 minutes (approximately 10%) :-)

Is there anyone that is aware of any issues by not updating the file
meta-data for every write? Is there any recovery scenarios where this
can make recovery fail? Derby seems to preallocates the log file
before starting using the file, so I think this should not influence
the ability to fine the last data written to the file after a power
failure.

Any comments?

Thanks,
Olav

Mime
View raw message