db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Date Tue, 21 Sep 2004 18:20:13 GMT
I have also observed that syncing does not take place on windows
platform if "write cache" is enabled.  Note that the microsoft
documentation for this setting notes that data may be corrupted if it is
enabled.  Unfortunately I think this option is enabled by default often
(I don't know if it is up to box hardware vendor, disk hardware vendor,
or OS software configuration).

The question is should the software not allow the user to tune this
behavior?  For instance on machines with redundant power supplies it may
be acceptable for the application to choose to run faster at a very low
risk.  I believe laptops fall into this category.  Note that I am not
arguing that there is ZERO risk.

When the change was made to go to from file sync to rws/rwd mode, suresh
and I worried about this issue, but the performance gain was so great
that I felt the change was worth making.  Users can turn off "write
cache" to be safer, microsoft documentation notes the safety tradeoffs
of the option.  Client applications the find this risk totally
unexceptable can use the property sent to the list to configure the
software to always use the old file sync method.

If anyone has time and access it might be interesting to see what other
databases do about this issue.  A simple benchmark that inserted one row
into a table and then updated a single integer column value to a
different value each time over and over again in autocommit mode should
be enough.  Any database that can do this at a rate greated than I/O
bandwith of the underlying disk is not syncing the log on commit.  Watch
out for underlying hardware, I got some wierd results on a relatively
inexpensive piece of server hardware, until I realized that it's
standard controller also included a battery backed 128 meg cache that
sat between the OS and disk - this thing is exactly what you need to get
rid of the standard short transaction log I/O bottleneck - works great
for derby.

Going forward it is likely users will request either no logging or in
memory logging options.  I believe many open source/inexpensive
databases provide these options - often making them the default out of
box configurations.  These are technically not very hard to provide,  if
it is acceptable that failures will likely be unrecoverable databases.
What do people think about these types of features?

Michael.Giroux@objectweb.org wrote:
> I've done a bit more testing on this and discovered that results are 
> significantly different if I disable the write cache on the device.  This 
> makes me question whether "rwd" is actually getting the data to disk 
> before it returns to the program.
> 
> rest deleted ...

Mime
View raw message