db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2020) Change file option for syncing log file to disk from rws to rwd
Date Tue, 13 Mar 2007 18:15:09 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-2020:
----------------------------------


I have been convinced by Olav's recent posting that  it is ok to use rwd - I won't block this
change, though I continue to think that the wording in the spec could be better.  I agree
that is likely on most if not all JVM's where we are doing the extra I/O in rws 
mode that it is unnecessary synchronous I/O.  It does make me slightly uneasy that we are
changing this mode for no reason on  some jvm's for no performance benefit (ie. on windows
machines we didn't see any performance difference between the 
two modes so choose the safer mode).

 I do think we should make sure 10.3 documentation reflects this change in behavior as I still
think the wording of the JVM spec is inexact.  I think we should document somewhere exactly
 what we are expecting from the JVM interfaces to guarantee a recoverable DB.  We have to
answer this question enough when explaining why we go slower than other DB's that don't sync
at all, we might as well be able to point to the documentation and to a release note for this
change.

On the MAC/FreeBSD issue, I am not sure we should go out of our way to recognize the problem.
 The previous workaround was put in because it came for "free", ie. did not penalize all the
JVM's for buggy implementations - and the system would not
even boot without the workaround.  If after this change the db
boots on these buggy JVM's but does not sync properly - I am not sure it is worth fixing.
 This is not much different than today's situation where you boot derby on a  machine where
you have the "write-sync" option disabled on the device (a default setting on many configurations).
   Best would be if we could code a solution that only caused extra work on the buggy JVM's.
 

> Change file option for syncing log file to disk from rws to rwd
> ---------------------------------------------------------------
>
>                 Key: DERBY-2020
>                 URL: https://issues.apache.org/jira/browse/DERBY-2020
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Store
>    Affects Versions: 10.3.0.0
>            Reporter: Olav Sandstaa
>         Assigned To: Olav Sandstaa
>         Attachments: disk-cache.png, no-disk-cache.png, rwd.diff, rwd.stat
>
>
> 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 some operating
> systems (e.g. Solaris) this leads to two write operation to the disk
> for every write issued by Derby. This is limiting the throughput of
> update intensive applications.  If we could change the file mode to
> "rwd" this could reduce the number of updates to the disk.
> 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 will attach some graphs that show
> this when running a given number of concurrent "tpc-b" like clients. These
> graphs show the throughput when running with "rws" and "rwd" mode when the
> disk's write cache has been enabled and disabled.
> I am creating this Jira to have a place where we can collect
> information about issues both for and against changing the default
> mode for writing to log files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message