<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR,
MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT
face=Tahoma>
<DIV><FONT face=Arial size=2>Bryan-</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>I believe that
I have a strategy using MVCC that completely
eliminates the concept of VLR log files.
I can outline it for you if desired - just
let me know.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>In terms of
performance, I suspect there are going to
be drastic differences between sequential
write performance using RandomAccessFile,
FileOutputStream, and the above used in conjunction
with or without mapped IO. Some of
these will have similar performance to random
writes, others should have much better performance.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Another area
of optimization that will be extremely interesting
to investigate is the use of direct channel
transfers - it may be considerably faster
to write memory to the safe, then do
a direct transfer from the safe into the
db (file -> file transfer) instead
of performing memory->file writes to the
db. This can't be looked at in isolation
from the write performance on the safe, though,
as it may cause the file system cache to
operate less efficiently...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The combinations/permutations
are like spaghetti, and there very well me
a dependence on a given jvm implementation.
If we are really good, we'll make sure to
design the thing so this aspect of the system
can be changed easily.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- K</FONT></DIV>
<DIV><FONT face=Arial size=2> </FONT>
<TABLE>
<TBODY>
<TR>
<TD width=1 bgColor=blue><FONT face=Arial
size=2></FONT></TD>
<TD><FONT face=Arial size=2><FONT color=red>>
Kevin,<BR><BR>I will run a test comparing
sequential writes on the safe with random<BR>writes.
There are two questions here of course.
One is whether the<BR>I/O is fully
optimized for sequential writes. The
other is whether<BR>the O/S provides a guarentee
that we can use to know that the safe<BR>header/trailing
record was written after the pages logged
on the safe<BR>and thereby provides a guarentee
that all pages were logged to the <BR>safe.<BR><BR>While
you are looking into this issue further,
let me raise one more<BR>issue for you. When
a dirty (changed) page is forced from the
cache<BR>to the database during a VLR Tx,
the clean page is first written on<BR>a log
for that VLR Tx. Unless we force the
log to disk after every<BR>such write, we
do not know that the BFIM page from the DB
is stable<BR>on the disk in the log file.
To get that guarentee we basically
need<BR>to address the same concerns which
you are citing for the safe.<BR><BR>I think
that persuing these questions is fruitful
since it will help<BR>us to understand better
the durability and recovery / failure of
the<BR>DBCache architecture. Some other
architectures, e.g., ARIES, might<BR>reduce
some risks by trading off some performance
characteristics.<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: <A href="mailto:jdbm-developer-admin@...
color=#0000ff>jdbm-developer-admin@...:
JDBM Developer listserv<BR>Sent: 3/6/2006
10:46 AM<BR>Subject: [Jdbm-developer] Research
on high performance sequential output...<BR><BR>Hi
all- Doing some research into the interaction
between Java and<BR>trying to get high performance
sequential output...<BR><BR><BR><BR>This
is one area of the dbcache safe design that
I've questioned in<BR>terms of applicability
to a Java implementation: namely, there
are no<BR>explicit constructs in Java IO
that instruct the OS to optimize it's<BR>buffering
for sequential output.<BR><BR><BR><BR>On
the win32 platform, you can tell the OS to
optimize for this kind of<BR>thing using
the FILE_FLAG_SEQUENTIAL_SCAN flag during
the CreateFile<BR>call. This kind of
thing *might* be done implicitly when you
open a<BR>fileoutputstream, but I'm not sure.<BR><BR><BR><BR>Anyway,
this could have implications to how the safe
is implemented...<BR>I'm not sure if it's
possible to perform a FileChannel seek()
on a<BR>channel obtained from a FileOutputStream
- but that will probably be our<BR>best bet
for performance if it works...<BR><BR><BR><BR>Here's
an article describing the option:<BR><A href="http://support.microsoft.com/kb/q98756/"><FONT
color=#0000ff>http://support.microsoft.com/kb/q98756/</FONT></A><BR><A
href="http://support.microsoft.com/kb/q98756/"><FONT
color=#0000ff><http://support.microsoft.com/kb/q98756/></FONT></A>
<BR><BR><BR><BR>The following is a decent
summary of test results performed under native<BR>win32:
<A href="http://world.std.com/~jmhart/atou.htm"><FONT
color=#0000ff>http://world.std.com/~jmhart/atou.htm</FONT></A><BR><A
href="http://world.std.com/~jmhart/atou.htm"><FONT
color=#0000ff><http://world.std.com/~jmhart/atou.htm></FONT></A>
<BR><BR><BR><BR>The following quote from<BR><A
href="http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html"><FONT
color=#0000ff>http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html</FONT></A><BR><A
href="http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html"><FONT
color=#0000ff><http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html</FONT></A><BR>>
is instructive:<BR><BR><BR><BR>FILE_FLAG_SEQUENTIAL_SCAN
informs the file system that the file will
be<BR>accessed sequentially. This allows
the file system to be more aggressive<BR>in
caching and perform read ahead/write behind
operations and also<BR>flushing/discarding
buffers once the I/O has progressed beyond
the<BR>location of the file contained within
the buffer. Benchmarks have shown<BR>that
FILE_FLAG_SEQUENTIAL_SCAN provides a negligible
improvement in read<BR>throughput, but provides
a noticeable improvement in write throughput.<BR><BR>The
following is an interesting support item
from another database<BR>system: <A
href="http://www.hbm.com/knowledge%20base/TB022.htm"><FONT
color=#0000ff>http://www.hbm.com/knowledge%20base/TB022.htm</FONT></A><BR><A
href="http://www.hbm.com/knowledge%20base/TB022.htm"><FONT
color=#0000ff><http://www.hbm.com/knowledge%20base/TB022.htm></FONT></A>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>-
K<BR><BR>-------------------------------------------------------
This SF.Net<BR>email is sponsored by xPML,
a groundbreaking scripting language that<BR>extends
applications into web and mobile media. Attend
the live webcast<BR>and join the prime developer
group breaking into this new coding<BR>territory!<BR><A
href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642"><FONT
color=#0000ff>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</FONT></A><BR>_______________________________________________
Jdbm-developer mailing<BR>list <A href="mailto:Jdbm-developer@...
color=#0000ff>Jdbm-developer@...
href="https://lists.sourceforge.net/lists/listinfo/jdbm-developer"><FONT
color=#0000ff>https://lists.sourceforge.net/lists/listinfo/jdbm-developer</FONT></A><BR><BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML>
|