db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steen Jansdal <st...@jansdal.dk>
Subject Re: java1.4.2 "rws" mode - log write performance - OSX numbers
Date Wed, 22 Sep 2004 06:42:20 GMT
Mike Matrigali wrote:
> 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?
> 

I 100% agree with you. We need this option. I can imagine a lot of
places where you don't need the fail-safe feature.

One of first things people do when they are checking out a new database 
is writing a little benchmark program inserting some records, querying 
them and compare them with a database they already know. One of these
known database are hsqldb which is very fast, but even though people
think it's failsafe because it uses a log file too, it's not. It has
a log sync thread that by default commits the log once every minute.

Steen

Mime
View raw message