Hi Jørgen, Thanks for the quick response. Due to our planned derby usage pattern (open derby, do something for a user request, close derby) this is more of an issue. This usage is done so that any mid-tier box can handle client requests and access the derby db on a nas/filer. I notice the following writes/fsyncs in a read only test, are they all due to the commit log record or is there another cause of the writes to log ctrl files:
1 - open: opened fd=36 ns=24000 flags=514 path '/testDBHome/simpleDerbyTest/log/log.ctrl' 1 - write: write of size=48 ns=22000 to fd 36 - /testDBHome/simpleDerbyTest/log/log.ctrl 1 - fsync: fsync ns=1378000 fd=36 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 1 - open: opened fd=36 ns=30000 flags=514 path '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 1 - write: write of size=48 ns=30000 to fd 36 - /testDBHome/simpleDerbyTest/log/logmirror.ctrl 1 - fsync: fsync ns=250000 fd=36 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' and another set when shutting down: 1 - write: write of size=144 ns=321000 to fd 35 - /testDBHome/simpleDerbyTest/log/log1.dat 0 - open: opened fd=40 ns=32000 flags=514 path '/testDBHome/simpleDerbyTest/log/log.ctrl' 0 - write: write of size=48 ns=20000 to fd 40 - /testDBHome/simpleDerbyTest/log/log.ctrl 0 - fsync: fsync ns=168000 fd=40 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 0 - close: close on fd=40 - '/testDBHome/simpleDerbyTest/log/log.ctrl' 0 - open: opened fd=40 ns=21000 flags=514 path '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 0 - write: write of size=48 ns=17000 to fd 40 - /testDBHome/simpleDerbyTest/log/logmirror.ctrl 1 - fsync: fsync ns=190000 fd=40 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 1 - close: close on fd=40 - '/testDBHome/simpleDerbyTest/log/logmirror.ctrl' 1 - close: close on fd=39 - '/testDBHome/simpleDerbyTest/seg0/cd1.dat' 1 - close: close on fd=36 - '/testDBHome/simpleDerbyTest/seg0/c10.dat' 1 - open_nocancel: opened fd=36 ns=27000 flags=1048580 path '/testDBHome/simpleDerbyTest/tmp' 1 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest/tmp' 1 - open_nocancel: opened fd=36 ns=19000 flags=1048580 path '/testDBHome/simpleDerbyTest' 0 - close: close on fd=38 - '/testDBHome/simpleDerbyTest/seg0/cc0.dat' 0 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest' 0 - open_nocancel: opened fd=36 ns=17000 flags=1048580 path '/testDBHome/simpleDerbyTest/seg0' 0 - close_nocancel: close on fd=36 - '/testDBHome/simpleDerbyTest/seg0' 0 - write: write of size=70 ns=264000 to fd 35 - /testDBHome/simpleDerbyTest/log/log1.dat -nick On Wednesday, April 15, 2009, at 12:07AM, "Jørgen Løland" <[email protected]> wrote: >Nick Puz wrote: >> I've been doing performance evaluation of derby for a potential project >> (using dtrace on osx and sun) and noticed that recovery is still run after >> doing what I thought was a clean shutdown. I've stepped through derby10.4 >> (svn rev 751303) with java 6 and can see that recovery is being run and the >> three operations being applied are: start tx, checkpoint, then endtx. >> >> Attached is a test program and copy of the dtrace output (showing file >> operations). The test program: >> 1) opens a connection to the db then closes it. >> 2) shuts down the db by opening a connection with ";shutdown=true" added to >> the url. >> 3) prompts for input (to add spacing to dtrace output/ start tracing) >> 4) repeats steps 1 & 2 -- starts on line 236 of attached dtrace output. >> >> >> Is there a way to close the DB to avoid the subsequent recovery actions on >> open? Not so much the recovery (i understand it has to check on startup) but >> the write/fsync of the log, log.ctrl, and logmirror.ctrl. > >The recovery algorithm will always be executed when you boot a database, >even when you have performed a clean shutdown like you have. Thus, the >{start tx, checkpoint, commit} sequence is the least amount of recovery >work currently possible in Derby. > >AFAIK, there's no way to avoid this sequence - I don't think anyone ever >considered writing a single block to disk at boot time would be a problem. > >You may consider adding a bug report about this if it causes problems >for you. Writing a patch for it would be even better if it is important >to you :-) > >BTW: should you consider working on this issue, the commit is what >causes the write to disk. The checkpoint does nothing in this case. > >-- >Jørgen Løland > >
