You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Øystein Grøvlen (JIRA)" <de...@db.apache.org> on 2006/01/09 11:45:30 UTC
[jira] Created: (DERBY-801) Allow parallel access to data files.
Allow parallel access to data files.
------------------------------------
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Type: Improvement
Components: Performance, Store
Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-801) Allow parallel access to data files.
Posted by Anders Morken <an...@stud.ntnu.no>.
Oystein Grovlen - Sun Norway:
> >Of course only people running Derby on 1.4+ JVMs will have the
> >opportunity to benefit from this approach. As support for 1.3 is to be
> >deprecated this might not be much of an issue?
>
> If this means that 1.3 still works, but the old way, I think this is
> acceptable.
It does. You can think of RAFContainer4 as an overlay on RAFContainer
- it only comes into play on 1.4+ JVMs: "if( JVMInfo.JDK_ID >=
JVMInfo.J2SE_14)".
The current code is quite cowardly, and falls back to the old
version if something goes wrong. =)
Thanks for the description of the benchmark, if I'm bored I might smash
together something based on it, but as I'm supposed to be preparing for
the exams next week instead of coding now that'll probably have to wait.
I've procrastinated enough as it is. ;)
I've put the patch in Jira (DERBY-801) after a little cleanup and
running storeall. Caveat: It needs some more work to be worthy of
consideration for the trunk, but at least it passes storeall. =)
Anyone interested is welcome to beat the c!!p out of it, maybe we can
turn it into something useful together? =)
Thanks,
--
Anders Morken
My opinions may have changed, but not the fact that I am right!
Re: [jira] Created: (DERBY-801) Allow parallel access to data files.
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Anders Morken wrote:
> I've played around a bit with a different approach - using the
> FileChannel class from Java 1.4's new IO API. I've written a class
> RAFContainer4 which extends RAFContainer and overrides the readPage and
> writePage methods of that class to use read/write(ByteBuffer buf, long
> postition) in FileChannel to access the container's file, without
> synchronizing on the FileContainer during the read and write calls.
>
> With a bit of hackery in BaseDataFileFactory#newContainerObject() this
> class is then used instead of the regular RAFContainer on creation of
> new RAFContainer objects when Derby runs in a 1.4+ JVM.
>
> This approach gives the JVM and OS the opportunity to issue multiple
> file operations concurrently, although we have no guarantees that this
> will actually happen. This is JVM/OS dependent, but stracing the Sun
> 1.4.2_09 VM on Linux 2.6 shows that the VM now uses pread64()/pwrite64()
> system calls instead of seek(), read() and write(). pread and pwrite
> have similar semantics to the FileChannel#read/write(ByteBuffer buf,
> long position) methods, and do not alter the file's seek() position, and
> are supposed to be thread safe.
Great, Anders. This looks like a promising idea.
>
> Of course only people running Derby on 1.4+ JVMs will have the
> opportunity to benefit from this approach. As support for 1.3 is to be
> deprecated this might not be much of an issue?
If this means that 1.3 still works, but the old way, I think this is
acceptable.
> But anyway, I would like to see if this hack of mine actually works. I
> see mentions of a "TPC-B like benchmark" in the threads Øystein links to
> above, and wonder if that is something Sun internal, or if it's a
> publicly available benchmark implementation that I can get my grubby
> little paws on and try out this patch with? =)
The actual code is something we have developed internally here, and I am
not sure we will have time to make it available any time soon. If you
make a patch of your changes, I should be able to test this next week.
If you want to try this out yourself, I think you should be able to make
a sufficient test client quickly. (However, it will take some time to
create the large database). What I used was:
1. A database much larger than physical memory on computer. I think I
had around 17 GB of data including indexes.
2. A large page cache. I used 500MB on a computer with 2GB RAM.
3. Log device on separate disk. (I.e., you need a computer with 2 disks.)
4. I used TPC-B like transactions, but I would accept that any load
where transactions access records in a large table by primary key should
work. Make sure to try to avoid frequent lock conflicts or deadlocks.
(E.g., two random accesses to the same table within a transaction is
dead-lock prone)
5. Multi-threaded application where all threads ran the same type of
transaction back-to-back. (I had 20 threads). Our application prints
throughput per thread and total throughput for every 10 second interval
and an average at the end.
6. Run for at least 30 mins to allow for several checkpoints to happen
during your run. (I ran for 1 hour).
A short description of our TPC-B like app:
4 tables:
branch(bid int, bbal int, junk char(92), primary key(bid))
teller(tid int, bid, int , tbal int, junk char(88), primary key(tid))
account(aid int, bid int, abal int, junk char(88), primary key(aid))
history(aid int, tid int, bid int, delta int, tstamp timestamp, primary
key(tstamp,aid,delta))
All primary keys are numbered from 0 to n-1, where n are the number of
rows in the table. *bal columns are initially 0.
teller: bid=tid/10, account:bid=aid/100000
I had 1000 branches, 10000 tellers and 100 million accounts. history
table is initially empty
A transaction has 5 statements:
update account set abal = abal+? where aid=? and bid=?
insert into history values (?, ?, ?, ?, CURRENT_TIMESTAMP)
update teller set tbal = tbal+? where tid=? and bid=?
update branch set bbal = bbal+? where bid=?
select abal from account where aid=y
In TPC-B there are some rules about selecting teller and account where a
certain percentage of transactions will use a teller from a different
branch than the branch of the account, but I do not think that will
matter here. I suggest by random determining a balance change (we use a
number between -1 million and 1 million), and a random aid and determine
tid and bid based on the aid. (I.e., tid=aid/10000, bid=tid/100000).
--
Øystein
Re: [jira] Created: (DERBY-801) Allow parallel access to data files.
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I have not reviewed the code, but your description of the approach and
the results posted later indicate this is a good path for this problem.
I would not worry about pre-1.4 jvm's not getting the benefit. As long
as the system still works then the separate module appoach is consistent
with other parts of the system.
In addition to showing that the fix helps the dual i/o case, it would
be nice to compare the pre and post performance of single user I/O just
to insure the new interfaces are not significantly slower than the old.
Anders Morken wrote:
> Øystein Grøvlen (JIRA):
>
>>Allow parallel access to data files.
>>------------------------------------
>>
>> Key: DERBY-801
>> URL: http://issues.apache.org/jira/browse/DERBY-801
>> Project: Derby
>> Type: Improvement
>> Components: Performance, Store
>> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
>> Environment: Any > Reporter: Øystein Grøvlen
>>
>>
>>Derby currently serializes accesses to a data file. For example, the
>>implementation of RAFContainer.readPage is as follows:
>>
>> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
>> fileData.seek(pageOffset); // fileData is a RandomAccessFile
>> fileData.readFully(pageData, 0, pageSize);
>> }
>>
>>I have experiemented with a patch where I have introduced several file
>>descriptors (RandomAccessFile objects) per RAFContainer. These are
>>used for reading. The principle is that when all readers are busy, a
>>readPage request will create a new reader. (There is a maximum number
>>of readers.) With this patch, throughput was improved by 50% on
>>linux. For more discussion on this, see
>>
>>http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
>>
>>The challenge with the suggested approach is to make a mechanism to
>>limit the number of open file descpriptors. Mike Matrigali has
>>suggested to use the existing CacheManager infrastructure for this
>>purpose. For a discussion on that, see:
>>
>>http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
>
>
> I've played around a bit with a different approach - using the
> FileChannel class from Java 1.4's new IO API. I've written a class
> RAFContainer4 which extends RAFContainer and overrides the readPage and
> writePage methods of that class to use read/write(ByteBuffer buf, long
> postition) in FileChannel to access the container's file, without
> synchronizing on the FileContainer during the read and write calls.
>
> With a bit of hackery in BaseDataFileFactory#newContainerObject() this
> class is then used instead of the regular RAFContainer on creation of
> new RAFContainer objects when Derby runs in a 1.4+ JVM.
>
> This approach gives the JVM and OS the opportunity to issue multiple
> file operations concurrently, although we have no guarantees that this
> will actually happen. This is JVM/OS dependent, but stracing the Sun
> 1.4.2_09 VM on Linux 2.6 shows that the VM now uses pread64()/pwrite64()
> system calls instead of seek(), read() and write(). pread and pwrite
> have similar semantics to the FileChannel#read/write(ByteBuffer buf,
> long position) methods, and do not alter the file's seek() position, and
> are supposed to be thread safe.
>
> Of course only people running Derby on 1.4+ JVMs will have the
> opportunity to benefit from this approach. As support for 1.3 is to be
> deprecated this might not be much of an issue?
>
> But anyway, I would like to see if this hack of mine actually works. I
> see mentions of a "TPC-B like benchmark" in the threads Øystein links to
> above, and wonder if that is something Sun internal, or if it's a
> publicly available benchmark implementation that I can get my grubby
> little paws on and try out this patch with? =)
>
> Thanks,
Re: [jira] Created: (DERBY-801) Allow parallel access to data files.
Posted by Anders Morken <an...@stud.ntnu.no>.
Øystein Grøvlen (JIRA):
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any > Reporter: Øystein Grøvlen
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
>
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
>
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
>
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
>
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
>
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
I've played around a bit with a different approach - using the
FileChannel class from Java 1.4's new IO API. I've written a class
RAFContainer4 which extends RAFContainer and overrides the readPage and
writePage methods of that class to use read/write(ByteBuffer buf, long
postition) in FileChannel to access the container's file, without
synchronizing on the FileContainer during the read and write calls.
With a bit of hackery in BaseDataFileFactory#newContainerObject() this
class is then used instead of the regular RAFContainer on creation of
new RAFContainer objects when Derby runs in a 1.4+ JVM.
This approach gives the JVM and OS the opportunity to issue multiple
file operations concurrently, although we have no guarantees that this
will actually happen. This is JVM/OS dependent, but stracing the Sun
1.4.2_09 VM on Linux 2.6 shows that the VM now uses pread64()/pwrite64()
system calls instead of seek(), read() and write(). pread and pwrite
have similar semantics to the FileChannel#read/write(ByteBuffer buf,
long position) methods, and do not alter the file's seek() position, and
are supposed to be thread safe.
Of course only people running Derby on 1.4+ JVMs will have the
opportunity to benefit from this approach. As support for 1.3 is to be
deprecated this might not be much of an issue?
But anyway, I would like to see if this hack of mine actually works. I
see mentions of a "TPC-B like benchmark" in the threads Øystein links to
above, and wonder if that is something Sun internal, or if it's a
publicly available benchmark implementation that I can get my grubby
little paws on and try out this patch with? =)
Thanks,
--
Anders Morken
My opinions may have changed, but not the fact that I am right!
Re: [jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by Suresh Thalamati <su...@gmail.com>.
Anders Morken wrote:
> Suresh Thalamati (JIRA):
>
>> [ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434613 ]
>>
<snip ..>
>>RAFContainerFactory.java
>>------------------------
>>
>>Logic in this new class seems to be deciding whether to load RafContainer.java or
>>the RafContainer4.java based on the JVM. I am not sure, if this logic is
>>necessary here. Did you consider using basic services to load the java classes
>>specific to a JVM ?
>
>
> Can you do that? Never occured to me, I'll check it out. Thanks for the
> tip. Any pointers and tips would be welcome, but given enough time and
> source code perusal I'll probably figure it out on my own as well. From
> a quick look at modules.properties it looks pretty straightforward, at
> least if adding "J4" to a module name means "load this in Java 1.4 and
> up". =)
you are are the right track. I have used this mechanism long time ago, you
might need to something like:
Replace the current data factory module entry
(:derby.module.rawStore.data.generic) with the following entries :
derby.module.rawStore.dataJ1=rg.apache.derby.impl.store.raw.data.BaseDataFileFactory
derby.env.jdk.dataJ1=1
derby.config.rawStore.dataJ1=derby
derby.module.rawStore.dataJ4=org.apache.derby.impl.store.raw.data.DataFileFactoryJava4
derby.env.jdk.dataJ4=4
derby.config.rawStore.dataJ4=derby
DataFileFactoryJava4 will be the new class extended from
BaseDataFileFactory.
>
>
>>I think basic services has support to boot a specific factory implementation
>>based on the JVM using modules.properties. For example in the current
>>scenario, one can extend BaseDataFileFactory.java class to
>>implement newContainerObject(), which will return the RafContainer4( ..). add
>>the new class to modules.properties to boot only on versions >=jdk14.
>>
>>
>>
>
>>4) I noticed, there is new encryption buffer created on every writePage() call,
>> if the database is encrypted. This may cause jvm peak memory usage increase,
>> when there is a checkpoint, if there are lot of dirty pages in the cache and
>> if garbage collection is not happening fast enough. I hope this does not
>> lead to out of memory errors!
>>
>> We may need to implement some kind of scheme, that will help in reuse of
>> the encryption buffers.
>
>
> This is a (classical) choice between concurrency and resource
> consumption. On one hand, object creation and garbage collection from
> the eden space is pretty cheap on 1.4 and newer VMs, but we'll force
> additional GC runs... This is a complex subject, with many variables. =)
>
> I suppose it could be interesting to do a little throughput testing with
> this patch and an encrypted database and see if there is any impact. I
> can't really say that I have any idea if recycling a single buffer or
> creating lots of buffers is the cheaper way...
>
I agree, new jvms are smarter. This problem can be addressed later, if
needed. On older jvms I used to run into out of memory problem when I
do some thing like that.
>
>>5) I am ok with readPage() and writePage() routines in RafContainer4.java.
>> just curious , if you considered implementing new read/write..etc calls in
>> the RafContainer4.java using file channel and just wrapper methods in the
>> RafContainer.java using the existing random access file, instead of
>> overriding readPage()/writePage() ...etc.
>
>
> Uhm, I'm sorry, I'm not sure I understand what you're thinking of here?
> Could you elaborate a bit? =)
To avoid dealing with changes to two copies of readPage/writePage
routines in
future fixes; I would have tried to abstract out just the code that is
really
different in jdk14 vs jdk13. For example :
in RafContainer.java , implement :
writeBuffer( .....) {
synchronized(this) {
fileData.seek( ...)
fileData.write( ..)
}
}
and in RafContainer4.java, override that routine :
writeBuffer(....) {
iochannel.write( ...)
}
similarly any other functionality you need. I undestand, it adds an
extra level to the call stack; my guess is that should not have major
performance impact.
For all I know , it may not be that simple ; Different exceptions
..etc. Please feel free to ignore this suggestion, if you think
current approach is good enough.
> If we wanted to go even further we could consider using memory mapped IO
> - then the parts of Derby that modify data pages could access the memory
> mapped file directly and save some overhead, but that probably requires
> a bit of a rework of some interfaces and the code that modifies data
> pages. And then we have the case of large databases and 32-bit address
> spaces... =)
>
It would be intersting to find, if that improves the performance further.
>
>>6) Please file a JIRA to enhance StorageFactory interfaces to support NIO.
>
>
> There's already DERBY-262 in Jira, but it's a bit unspecific... Anything
> in particular you think needs to be added to the interfaces?
DERBY-262 is a very generic NIO entry. I think it would be better to
file a separate JIRA entry that will describe the changes needed in
the storage factory to implement what you are doing in this fix using
the storage factory, instead of limiting the RAFContainer4.java usage
only to storage factory that is based on the java.io.RandomAccessFile.
Thanks
/suresh
Re: [jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by Anders Morken <an...@stud.ntnu.no>.
Suresh Thalamati (JIRA):
> [ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434613 ]
>
> Suresh Thalamati commented on DERBY-801:
> ----------------------------------------
>
> Thanks for working on this issue, Anders. I really like your solution to solve
> this issue. Patch is very good, I have only few minor comments/questions.
> I am really sorry for not reviewing it sooner.
Heh, my progress hasn't exactly been fast either. =)
> RAFContainerFactory.java
> ------------------------
>
> Logic in this new class seems to be deciding whether to load RafContainer.java or
> the RafContainer4.java based on the JVM. I am not sure, if this logic is
> necessary here. Did you consider using basic services to load the java classes
> specific to a JVM ?
Can you do that? Never occured to me, I'll check it out. Thanks for the
tip. Any pointers and tips would be welcome, but given enough time and
source code perusal I'll probably figure it out on my own as well. From
a quick look at modules.properties it looks pretty straightforward, at
least if adding "J4" to a module name means "load this in Java 1.4 and
up". =)
> I think basic services has support to boot a specific factory implementation
> based on the JVM using modules.properties. For example in the current
> scenario, one can extend BaseDataFileFactory.java class to
> implement newContainerObject(), which will return the RafContainer4( ..). add
> the new class to modules.properties to boot only on versions >=jdk14.
>
>
>
> In RafContainer4.java :
> ---------------------
>
> 1) I think following import is not needed.
>
> +import java.io.*;
I've narrowed it down to java.io.IOException. =)
>
> 2) Is it really necessary to rewind() the buffers in readFull/writeFull ? From what I understood,
> there is a new ByteBuffer object being created on both read/write page
> methods.
>
> + dstBuffer.rewind(); // Reset buffer position before we start read
> and
> + srcBuffer.rewind(); // Reset buffer position before we start writing.
Naah, not really. Just unnecessary paranoia. =)
> 3) do we really need the following method ?
>
> + final protected FileChannel getChannel() {
> + return ourChannel;
> + }
Naah, not really. It acted as a synchronization point at one time in the
life of the patch, but the synchronization has been made excplicit in
readPage() and writePage() instead at a later stage. =)
> 4) I noticed, there is new encryption buffer created on every writePage() call,
> if the database is encrypted. This may cause jvm peak memory usage increase,
> when there is a checkpoint, if there are lot of dirty pages in the cache and
> if garbage collection is not happening fast enough. I hope this does not
> lead to out of memory errors!
>
> We may need to implement some kind of scheme, that will help in reuse of
> the encryption buffers.
This is a (classical) choice between concurrency and resource
consumption. On one hand, object creation and garbage collection from
the eden space is pretty cheap on 1.4 and newer VMs, but we'll force
additional GC runs... This is a complex subject, with many variables. =)
I suppose it could be interesting to do a little throughput testing with
this patch and an encrypted database and see if there is any impact. I
can't really say that I have any idea if recycling a single buffer or
creating lots of buffers is the cheaper way...
> 5) I am ok with readPage() and writePage() routines in RafContainer4.java.
> just curious , if you considered implementing new read/write..etc calls in
> the RafContainer4.java using file channel and just wrapper methods in the
> RafContainer.java using the existing random access file, instead of
> overriding readPage()/writePage() ...etc.
Uhm, I'm sorry, I'm not sure I understand what you're thinking of here?
Could you elaborate a bit? =)
When I started work on this patch, readPage() and writePage() just
seemed like the smallest pieces of RAFContainer that could be replaced
easily to retrofit NIO support. I agree if you think the current
solution is a bit of a "bolt-on" fix, but it was relatively non-invasive
in the original code (which appealed to me as a newbie to Derby) and
hopefully efficient enough on new JVMs anyway.
If we wanted to go even further we could consider using memory mapped IO
- then the parts of Derby that modify data pages could access the memory
mapped file directly and save some overhead, but that probably requires
a bit of a rework of some interfaces and the code that modifies data
pages. And then we have the case of large databases and 32-bit address
spaces... =)
> 6) Please file a JIRA to enhance StorageFactory interfaces to support NIO.
There's already DERBY-262 in Jira, but it's a bit unspecific... Anything
in particular you think needs to be added to the interfaces?
Thanks for your advice,
--
Anders Morken
My opinions may have changed, but not the fact that I am right!
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12429015 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Hi Anders,
Thank you for working on this issue! I have looked at your patch, and
my impression is that your approach looks good and complete. A couple
of comments and questions follows.
First to your questions in JIRA and in the comments:
1) I don't think casting dataFile to RandomAccessFile is such an ugly
hack. You check that it is an instance of RandomAccessFile before
you cast it, and fall back to the old behaviour if it is not. Seems
perfectly safe to me.
If you're really determined to clean up the interfaces, I would
suggest that the implementations of StorageRandomAccessFile
contained a RandomAccessFile instance instead of extending the
class. Then the StorageRandomAccessFile interface could be changed
to provide a FileChannel-like abstraction. In that case, there
would be only one implementation of RAFContainer (and it would look
very much like your RAFContainer4), but the implementations of
StorageRandomAccessFile would have to differ between different VMs
(that is, on jvm>=1.4 they would use FileChannel under the hood, on
jvm 1.3 they would pretend that they did, but actually serialize
reads and writes).
2) In a comment to a try/finally statement where the finally clause
only contains debug code, you write that you hope the compiler will
optimize it away. I think this is a reasonable expectation.
Then to my own comments:
3) I'm not sure the access to needsSync is thread safe even though you
have declared it as volatile. All accesses to it in RAFContainer
are synchronized on the RAFContainer instance, but the one in
RAFContainer4 is not. I think this can lead to race conditions,
such as:
Thread 1 is invoking RAFContainer.clean() which calls
writeRAFHeader() and clearDirty() in a synchronized block.
At the same time, thread 2 is executing RAFContainer4.writePage()
which contains the assignment "needsSync = true" without any
synchronization.
It is possible that needsSync is assigned to true after thread 1
invokes writeRAFHeader() but before it invokes clearDirty(). Since
clearDirty() sets needsSync to false, the second thread's request
for syncing disappears.
If the assignment were changed to
synchronized (this) { needsSync = true; }
I think it would be thread safe (there would be no way to change
the value of needsSync between writeRAFHeader() and clearDirty()).
4) Is the synchronization in RAFContainer4.updatePageArray() needed?
There is no synchronization in RAFContainer.updatePageArray(). To
me, it seems like RAFContainer.updatePageArray() could be used
directly (but you'll have to check whether the database is
encrypted and allocate a new encryption buffer if it is). Is there
a particular reason why RAFContainer4 needs its own
updatePageArray()?
5) Should there have been iosInProgress++ and iosInProgress-- in the
"if (syncPage)" part of RAFContainer4.writePage() too?
6) The two new java files added by your patch use a mix of tabs and
spaces as indentation character. It would be better if they
consistently used spaces. And extra bonus if none of the lines
exceed 80 characters. :)
7) Apache has decided that we should use another licence notice in the
file headers. You could just copy the new text from another file
(you might need to run 'svn up' since this was changed recently).
8) The RAFContainer4 class and the RAFContainerFactory class could be
package protected, not public.
9) In RAFContainer4, ourChannel and iosInProgress could be private.
10) In RAFContainerFactory, the comment to rafContainerConstructor
says "Immutable, initialized by constructor." Since this is the
case, I would prefer that it was made explicit in the code by
declaring it as final. And it could be made private (and maybe
static).
11) RAFContainer.padFile() was changed from private to protected, but
that is not needed since padFile() isn't used in RAFContainer4.
12) Javadoc for RAFContainer4.writeFully() says "readFully" instead of
"writeFully".
13) The javadocs for the classes look great! If you could add <p>
between the paragraphs, they would look great after they have been
transformed into HTML files as well. :)
14) RAFContainerFactory.newRAFContainer() could be written more
compactly if "return new RAFContainer(factory);" were moved out of
the catch clause and the else clause. :)
With the exception of 3 and 4, these comments are really minor
nits. (I was in a picky mood today, sorry! ;) ). You have done a great
job! Thank you very much!
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Øystein Grøvlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12413841 ]
Øystein Grøvlen commented on DERBY-801:
---------------------------------------
I have run our tpc-b like benchmark on with and without your patch on a 2-CPU opteron box with 2 local disks running Linux.
Results:
Without patch: Throughput: 70 tps. Max response time: 47.8 seconds
With patch: Throughput: 106 tps. Max response time: 4.5 seconds
All tests were run on the same database (17.5 GB) with a 500 MB page cache. For each code version I ran 2 tests each lasting 1 hour.
I think this looks very good. It increases throughput with 50% and reduces the max response time with 90%. I think this is comparable to the results I saw with multiple file descriptors per file. However, your solution is much cleaner. Do think much work is remaining on this patch to make it ready for production?
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Attachments: NIO-RAFContainer-v1.patch
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12435798 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Backed out the changes for DERBY-733 with the following commands:
svn merge -r 357275:357274 .
svn merge -r 356884:356883 .
Derbyall ran cleanly. Committed revision 447856.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Derby Info: [Patch Available]
DERBY-801-7.patch passed derbyall, by the way. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
"Suresh Thalamati (JIRA)" <de...@db.apache.org> writes:
> 4) I noticed, there is new encryption buffer created on every
> writePage() call, if the database is encrypted. This may cause jvm
> peak memory usage increase, when there is a checkpoint, if there are
> lot of dirty pages in the cache and if garbage collection is not
> happening fast enough. I hope this does not lead to out of memory
> errors!
This shouldn't cause out of memory errors. If the buffers are not
gc'ed fast enough, the checkpoint thread will be stalled until there
is enough memory for it to continue. Since the checkpoint thread only
writes one page at a time, the gc thread should be able to free all of
the old buffers.
--
Knut Anders
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434613 ]
Suresh Thalamati commented on DERBY-801:
----------------------------------------
Thanks for working on this issue, Anders. I really like your solution to solve
this issue. Patch is very good, I have only few minor comments/questions.
I am really sorry for not reviewing it sooner.
RAFContainerFactory.java
------------------------
Logic in this new class seems to be deciding whether to load RafContainer.java or
the RafContainer4.java based on the JVM. I am not sure, if this logic is
necessary here. Did you consider using basic services to load the java classes
specific to a JVM ?
I think basic services has support to boot a specific factory implementation
based on the JVM using modules.properties. For example in the current
scenario, one can extend BaseDataFileFactory.java class to
implement newContainerObject(), which will return the RafContainer4( ..). add
the new class to modules.properties to boot only on versions >=jdk14.
In RafContainer4.java :
---------------------
1) I think following import is not needed.
+import java.io.*;
2) Is it really necessary to rewind() the buffers in readFull/writeFull ? From what I understood,
there is a new ByteBuffer object being created on both read/write page
methods.
+ dstBuffer.rewind(); // Reset buffer position before we start read
and
+ srcBuffer.rewind(); // Reset buffer position before we start writing.
3) do we really need the following method ?
+ final protected FileChannel getChannel() {
+ return ourChannel;
+ }
4) I noticed, there is new encryption buffer created on every writePage() call,
if the database is encrypted. This may cause jvm peak memory usage increase,
when there is a checkpoint, if there are lot of dirty pages in the cache and
if garbage collection is not happening fast enough. I hope this does not
lead to out of memory errors!
We may need to implement some kind of scheme, that will help in reuse of
the encryption buffers.
5) I am ok with readPage() and writePage() routines in RafContainer4.java.
just curious , if you considered implementing new read/write..etc calls in
the RafContainer4.java using file channel and just wrapper methods in the
RafContainer.java using the existing random access file, instead of
overriding readPage()/writePage() ...etc.
6) Please file a JIRA to enhance StorageFactory interfaces to support NIO.
/suresh
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-801) Allow parallel access to data files.
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Øystein Grøvlen closed DERBY-801.
---------------------------------
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: https://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Fix For: 10.3.0.0
>
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434965 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
I will hold the commit until Anders has responded to the questions from Suresh.
1, 2 and 3 seem like trivial changes which should be easy to fix. Suresh, if these were fixed, do you think the patch could be committed and the other issues addressed in followup patches? I think it sounds reasonable to make these changes incrementally (if only to make it easier to review the next revision of the patch). The current patch clearly is an improvement, and the optimizations/improvements suggested by Suresh would improve it further.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Derby Info: [Patch Available]
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Øystein Grøvlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443260 ]
Øystein Grøvlen commented on DERBY-801:
---------------------------------------
I saw the above error when developing the LobLengthTest, but it went away after I made some changes to the test. One of the changes I made was that the test was run earlier in the suite. Knut Anders' guess may explain this since my changes may have changed the possibility of running the test concurrently with checkpointing. The reason the problem hits this test may be that the table has probably allocated more blocks that any of the other tests in the suite (It inserts a16MB blob).
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Anders Morken (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12413541 ]
>
> Anders Morken commented on DERBY-801:
> -------------------------------------
>
> I've found a benchmark to test this patch with, and quite frankly I'm not seeing any difference in throughput between my patch and the original at all.
> I've tested on a 4x400MHz Sun Enterprise 450 with a 10-disk ZFS raid0 of old disks for data and logs and my own single-cpu 2,4GHz Athlon64 with a two disk raid0 for data and a single disk for logs.
How large was your database? Note that if the database is not
substantially larger that the amount of physical memory, the file system
may able to cache most of your data. In that case, you will not gain
much extra from concurrent I/O.
A metric I have found useful to is the average and maximum times for I/O
requests. That can give some indications on the queuing effects of I/O.
I have just measured the time by calls to System.currentTimeMillis()
in readPage/writePage.
--
Øystein
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12413541 ]
Anders Morken commented on DERBY-801:
-------------------------------------
I've found a benchmark to test this patch with, and quite frankly I'm not seeing any difference in throughput between my patch and the original at all.
I've tested on a 4x400MHz Sun Enterprise 450 with a 10-disk ZFS raid0 of old disks for data and logs and my own single-cpu 2,4GHz Athlon64 with a two disk raid0 for data and a single disk for logs.
Anyway, I think I'll need to work a bit harder on making more of the RAFContainer methods called by readPage and writePage thread safe, so we can ditch more of the synchronization still left in them. Øystein, don't waste too much time on testing this patch yet, it needs more work. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Attachments: NIO-RAFContainer-v1.patch
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12430262 ]
Anders Morken commented on DERBY-801:
-------------------------------------
Oh, and yes, it still passes tests. storeall ran flawlessly, derbyall failed in the derbynetmats suite's jdbcapi/checkDriver.java test because it got a "connection refused" error when connecting. Hopefully unrelated. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443040 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
I'm wondering whether we should change the DEBUG_PRINT calls to ASSERT/THROWASSERT. Falling back to the old implementation on errors is a good approach in insane mode, but I think the errors should be exposed in sane mode so we can see them and fix them.
After running the JUnit tests (java junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All) I noticed that derby.log contained this message (but no tests failed):
DEBUG RAFContainerFactory OUTPUT: Caught exception when setting up rafContainerConstructor
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12446609 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
> if we agree that closing a container that is being dropped while IO is still active on it is sane, it shouldn't be a source of noise.
I think that sounds OK. You have already code in writePage() to take care of this situation. Should readPage() have the same logic (that is, catching IOExceptions and checking committed-drop state)?
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12449848 ]
Suresh Thalamati commented on DERBY-801:
----------------------------------------
Hi Anders,
I agree with Knut, this issue can be marked as fixed, Thanks a lot for working on this improvement.
-suresh
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Fix For: 10.3.0.0
>
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Derby Info: [Patch Available]
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12435677 ]
Anders Morken commented on DERBY-801:
-------------------------------------
Suresh, Knut Anders, thanks for your advice. There's no need to rush this patch for my part, I'll be happy to provide a new one incorporating Suresh' suggestions. They probably end up making the whole patch smaller, as most of it is about removing redundant code (such as my homegrown RAFContainerFactory). I've already fixed 2) and 3) in my working copy, and I plan to take a long, hard look at 1) tonight. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443179 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Army Brown reported an intermittent assert failure in a comment to DERBY-1976. It is probably related to this issue. The assert error is thrown when a DROP TABLE is committed. Could it be that a checkpoint is writing pages in that table's container while the container is dropped/closed? Only guessing...
> I ran the JUnit suite "suites.All" against ibm142, jdk142, ibm15, jdk15, and jdk16 on a Windows 2000 machine. The only failure I saw was an intermittent failure in LobLengthTest on jdk15:
>
> There was 1 error:
> 1) testLongLobLengths(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest)
> java.sql.SQL Exception: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC:
> org.apache.derby.shared.common.sanity.AssertFailure#ASSERT FAILED Container closed
> while IO operations are in progress. This should not happen.#XJ001.U
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
> at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345)
> at org.apache.derby.client.am.Connection.commit(Connection.java:555)
> at org.apache.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:159)
> at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest.tearDown(LobLengthTest.java:87)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1,
> SQLSTATE: XJ001, SQLERRMC: org.apache.derby.shared.common.sanity.AssertFailure#ASSERT
> FAILED Container closed while IO operations are in progress. This should not happen.#XJ001.U
> at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:1920)
> at org.apache.derby.client.net.NetConnectionReply.parseRDBCMMreply(NetConnectionReply.java:215)
> at org.apache.derby.client.net.NetConnectionReply.readLocalCommit(NetConnectionReply.java:147)
> at org.apache.derby.client.net.ConnectionReply.readLocalCommit(ConnectionReply.java:43)
> at org.apache.derby.client.net.NetConnection.readLocalCommit_(NetConnection.java:1574)
> at org.apache.derby.client.am.Connection.readCommit(Connection.java:639)
> at org.apache.derby.client.am.Connection.flowCommit(Connection.java:588)
> at org.apache.derby.client.am.Connection.commit(Connection.java:551)
> ... 33 more
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Knut Anders Hatlen updated DERBY-801:
-------------------------------------
Fix Version/s: 10.3.0.0
Derby Info: (was: [Patch Available])
Committed revision 474695.
I don't think there is much left before the issue can be marked as resolved. Suresh had some comments, and I don't think that (4) and (6) have been addressed yet. If you file JIRAs for those two issues, this one could be closed.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Fix For: 10.3.0.0
>
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Mike Matrigali updated DERBY-801:
---------------------------------
Derby Info: (was: [Patch Available])
I am unsetting the patch available flag as the submittter has indicated that we should not apply this patch, and wait for another patch.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12413925 ]
Anders Morken commented on DERBY-801:
-------------------------------------
Ooh, very cool to see those numbers. Thanks for testing it despite my
pessimism. I probably haven't been running the benchmark I found
floating around the net on a big enough scale - while I have generated a
16.5 GB database, I haven't been patient enough to run the tests
properly. =)
Off the top of my head, things that need fixing are:
1) The class loading/initialization tricks in BaseDataFileFactory -
there's no need to do all that reflection every time we open a
container. Could probably be done in a static initializer, the boot
method or a constructor. (Which one is appropriate? The boot method?)
2) A couple of hackish casts in the wrapping methods that retrieve the
FileChannel object when the Container's identity is set. Dunno if these
should be left in or we should change the StorageRandomAccessFile
interface to extend java.io.RandomAccessFile? Both the two
implementations are extensions of java.io.RandomAccessFile, so the "this
cast works" assumption is pretty safe (as well as defensively
implemented) now, but assumption is the mother of all **ck-ups? =)
3) Handling exceptions from FileChannel properly. The current code
handles IOExceptions by padding the file and trying again. I have no
idea if the pad-the-file trick is of any use at all with FileChannel -
it was simply retained from the original implementation. Maybe padFile
should be refitted for FileChannel as well?
3.5) There's probably a bug in the original implementation of
RAFContainer#writePage(): If the catch(IOException e) {...try again...}
path is executed, updatePageArray() is not called, so modifications such
as adding the container header to the first page will be done (unless it
was done before the IOException was thrown) - and perhaps a security
issue: the page written will not be encrypted. The fact that this hasn't
been discovered by encryption tests is probably an indicator that this
codepath doesn't succeed where the first attempt failed very often.
Anyway, I'll make a separate Jira issue for this.
4) Skip more synchronization? Low priority, but I think there's a few
cases where one or more synchronizations could be merged into one block
or removed altogether - but thread safety is a delicate matter.
5) And last but not least, anything else code review turns up, of
course. =)
I'll see if I have some time to work on this later this week. Thanks for
the help, Øystein. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Attachments: NIO-RAFContainer-v1.patch
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-7.patch
This patch (DERBY-801-7.patch) turns the DEBUG_PRINT messages in RAFContainer4 into assertions guarding the method entry points. Dunno if they're of any use now, but if they catch a bug later, they could be worth the overhead in debug builds. =)
M java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java
RAFContainer4.java | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
Anything else I need to do before marking this one as resolved? =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12435752 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Committed v4 into trunk with revision 447815. Fixed Suresh's comments 1-3 in RAFContainer4 before committing. Now that RAFContainer is no longer used in jdk 1.5, I will back out the patch for DERBY-733.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12446607 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
I couldn't build the jar files with this patch because the build system expected cloudscape.config.rawStore.data.generic to have a J1/J4 suffix. When I removed the old cloudscape.config line from modules.properties and inserted one with J1 and one with J4, the jars were built just fine. I verified that RAFContainer4 was loaded when using JDK 1.5. Derbyall and the JUnit tests ran cleanly. Committed the modified patch with revision 470362. Thanks Anders!
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken reassigned DERBY-801:
-----------------------------------
Assignee: Anders Morken
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-801:
--------------------------------
Derby Categories: [Performance]
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: https://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assignee: Anders Morken
> Fix For: 10.3.1.4
>
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12446767 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Thanks Anders. I committed DERBY-801-6.patch with revision 470573.
> I'm not sure checking for the committed drop state in the readPage
> method is something we want to do - flushing the cache into a black
> hole is one thing, trying to read data that is supposed to be gone
> is another
You are of course right about the error checking in readPage().
> I've sort of got a feeling that maybe we are masking a problem here
> - should anyone (even the cache?) write to a dropped container?
Actually, I think it's the other way around. We are not writing to a
dropped container, but dropping a container which we happen to be
writing to. Since the dropping of the container has been committed, we
know that we'll never need those pages, so there's no need to complete
the write operations. The alternative would be to let closeContainer()
wait until all write operations on the container have finished.
> Maybe we should remove pages destined for a dying container from the
> cache when the container is dropped?
After the container has been dropped, it shouldn't be a problem
because getCommittedDropState() returns true, so writePage() will
return immediately without trying to write the page. Also, the pages
will be marked as invalid so that the cache space can be reclaimed.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12429018 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
When this fix gets into the codeline, the fix for DERBY-733 could be backed out.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by Anders Morken <an...@stud.ntnu.no>.
Suresh Thalamati:
> I doubt reading from a commit dropped container happen through the
> readPage() call in parallel to drops. Locks/Latches/flags should
> make sure that does not occur. I think only time we may read from the
> dropped container may be during recovery, if there is a crash just
> before stub was created for the dropped container, if container marked
> commit dropped , then I think only header is read , but that info is
> read by reading directly few bytes from the first page.
OK, so if this actually happened it would be appropriate to throw
exceptions. Good, that's what'll happen now. =)
> >I've sort of got a feeling that maybe we are masking a problem here -
> >should anyone (even the cache?) write to a dropped container?
>
> Pages are discarded from cache before the container is stubbed. See
> (removeContainer.pageCache.discard(identity .
>
> >Maybe we should remove
> >pages destined for a dying container from the cache when the
> >>container is dropped? =)
>
> I agree with removing/closing container does not seem to be the right
> thing to do when I/O is in progress. Having said that, I am also
> wondering if it is a over-kill to add more synchronization for this
> case. May be catching for ClosedChannelException is good enough .
OK, I'll take a harder look at what's happening when somebody writes to
a dropped container.
> One more thing I alos noticed going through the code again is
> DEBUG_PRINT("RAFContainer4"," .. statements. As Knut mentioned , they
> of no use. No one looks at them unless a test fails. If those cases
> should not happen , then throwing an ASSERT failure is better,
> otherwise please remove those PRINT statements.
OK, I changed the two DEBUG_PRINT statements in readPage/writePage to
asserts, ran derbyall, and whaddayaknow, it breaks something. =)
The problem is caused by openContainer checking for "fileData instanceof
java.io.RandomAccessFile" and then calling the getChannel() method to
get hold of a FileChannel object, when a CorruptRandomAccessFile (which
is not a java.io.RandomAccessFile) is used as a stand-in for a regular
file for testing purposes. Again, not something that'll happen during
regular operations, but it could be considered a symptom of the somewhat
hackish assumption that a regular java.io.RandomAccessFile is hiding
under the derby.io.StorageRandomAccessFile interface. =)
So, either the asserts should check for "fileData instanceof
java.io.RandomAccessFile" as well, or we throw them out. Or I rework the
o.a.derby.io interfaces a bit to support channels.
I'll run tests on the first approach tomorrow. Jämtlands bryggeri make
some excellent beer, but I doubt it's good for my coding and debugging
skills. ;)
Thanks for the advice, Suresh. (And Knut Anders as well, of course. =)
--
Anders Morken
My opinions may have changed, but not the fact that I am right!
Re: [jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by Suresh Thalamati <su...@gmail.com>.
Anders Morken (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
>
> Anders Morken updated DERBY-801:
> --------------------------------
>
> Attachment: DERBY-801-6.patch
>
> DERBY-801-6.patch remedies the noise from the iosInProgress sanity checking by checking the committed drop state before croaking.
>I've run jdbcapi/LobLengthTest.junit 100 times in a row now without seeing any problems,
> and I used to see the problem once every four or five runs without this patch.
>
> RAFContainer4.java | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletion(-)
>
Thanks for continuing to improve the fix for this problem, Anders.
> I'm not sure checking for the committed drop state in the readPage method is something
>we want to do - flushing the cache into a black hole is one thing, trying to read data that
>is supposed to be gone is another - I think I'd want to know if we had some logic that permitted
>reading from a dropped container. =)
I doubt reading from a commit dropped container happen through the
readPage() call in parallel to drops. Locks/Latches/flags should
make sure that does not occur. I think only time we may read from the
dropped container may be during recovery, if there is a crash just
before stub was created for the dropped container, if container marked
commit dropped , then I think only header is read , but that info is
read by reading directly few bytes from the first page.
>
> I've sort of got a feeling that maybe we are masking a problem here -
> should anyone (even the cache?) write to a dropped container?
Pages are discarded from cache before the container is stubbed. See
(removeContainer.pageCache.discard(identity .
> Maybe we should remove
> pages destined for a dying container from the cache when the
>> container is dropped? =)
I agree with removing/closing container does not seem to be the right
thing to do when I/O is in progress. Having said that, I am also
wondering if it is a over-kill to add more synchronization for this
case. May be catching for ClosedChannelException is good enough .
One more thing I alos noticed going through the code again is
DEBUG_PRINT("RAFContainer4"," .. statements. As Knut mentioned , they
of no use. No one looks at them unless a test fails. If those cases
should not happen , then throwing an ASSERT failure is better,
otherwise please remove those PRINT statements.
Thanks
-suresh
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-6.patch
DERBY-801-6.patch remedies the noise from the iosInProgress sanity checking by checking the committed drop state before croaking. I've run jdbcapi/LobLengthTest.junit 100 times in a row now without seeing any problems, and I used to see the problem once every four or five runs without this patch.
RAFContainer4.java | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletion(-)
I'm not sure checking for the committed drop state in the readPage method is something we want to do - flushing the cache into a black hole is one thing, trying to read data that is supposed to be gone is another - I think I'd want to know if we had some logic that permitted reading from a dropped container. =)
I've sort of got a feeling that maybe we are masking a problem here - should anyone (even the cache?) write to a dropped container? Maybe we should remove pages destined for a dying container from the cache when the container is dropped? =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-v3.patch
DERBY-801-v3.patch is a cleaned up version of DERBY-801-v2.patch.
First off, thanks to Knut Anders for a thorough review - I appreciate it, even the
nitpicking. Part of my motivation for doing this is to get rid of my bad habits. =)
Now, about this patch - I'll just reply to KAH's comments in the order they appeared.
1) I didn't particularly feel like modifying the interfaces in this patch.
Incremental development, right? ;-) Maybe we should stick a note in JIRA about it.
The problem with the instanceof check is that RAFContainer4 will fall back to old
behavior on tests that utilize the functionTests/util/corruptio/CorruptRandomAccessFile
class to simulate a broken file, and thus it won't be tested there. May not really be an
issue now, but could be one in a similar case later. Maybe I'm just paranoid. =)
2) OK =)
3) Good point, fixed.
4) updatePageArray() was only called from within a synchronized block before, so I
didn't trust it to be MT-safe. To make the fast path lock-free I moved the synchronization
inside the if/else blocks. Could be removed if you're sure it's safe? =)
5-14) Thanks, fixed. =)
I've tried to make sure the code adheres to the Java Coding Conventions now. I made one
exception (hopefully for the better): after a method head/if condition has been broken into multiple
lines I've used a newline before the { to make it easier to spot where the method head ends and
the body starts. Should be quick to fix if you disagree with me, anyway. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12430721 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Thanks for addressing my comments, Anders. I see your point about
CorruptRandomAccessFile, but that is a test issue which could be
addressed later.
I still think it would be safe to use the old, unsynchronized
updatePageArray(). It is true that it is called from within a
synchronized block in RAFContainer.writePage(), but it is also called
with no synchronization in RAFContainer.privBackupContainer(). If you
look at privBackupContainer(), you'll see that the page is latched
before the call to updatePageArray(), and I think it is safe to assume
that the page is latched before a call to readPage() or writePage() as
well.
One more question: Is it possible that the container enters the
committed drop state while RAFContainer4.writePage() is executing? If
yes, what are the consequences?
I haven't figured out yet why the original code checks the value
returned by getCommittedDropState() in writePage(), but only has an
assert in readPage().
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Knut Anders Hatlen updated DERBY-801:
-------------------------------------
Derby Info: (was: [Patch Available])
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12434420 ]
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------
Thank you, Anders! I think the patch looks very good, and unless someone objects within a couple of days, I will commit it. Since the patch touches such a critical part of the system, I don't think we should port it to 10.2 this late in the release process.
Derbyall ran cleanly on Solaris 10 x86, Sun JVM 1.5.0.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12435610 ]
Suresh Thalamati commented on DERBY-801:
----------------------------------------
Hi Knut ,
Patch is good. It is ok with me , if you would like to commit the current patch and let Anders address, other enhancements in the followup patches.
Thanks
-suersh
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-v5.patch
I'm attaching a patch (DERBY-801-v5.patch (relative to trunk), which incorporates Suresh's suggestion that I use the built-in Monitor mechanisms to boot an appropriate version of the BaseDataFileFactory. This removed a bunch of useless code, and should fix the "Caught exception when setting up rafContainerConstructor" errors. =)
M java/engine/org/apache/derby/modules.properties
M java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
A java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java
D java/engine/org/apache/derby/impl/store/raw/data/RAFContainerFactory.java
M java/engine/org/apache/derby/impl/store/build.xml
$ diffstat DERBY-801-v5.patch
impl/store/build.xml | 2
impl/store/raw/data/BaseDataFileFactory.java | 29 +++---
impl/store/raw/data/BaseDataFileFactoryJ4.java | 47 ++++++++++
impl/store/raw/data/RAFContainerFactory.java | 110 -------------------------
modules.properties | 8 +
5 files changed, 73 insertions(+), 123 deletions(-)
derbyall passed without errors - it just took me a loong while to actually get around to running derbyall on this one. =)
I've also played with the LobLengthTest.junit test and provoked the error message, and what I've seen is that the problem happens when the container is being closed and deleted - the very same race condition case Knut Anders pointed out in previous comments. This happens when one thread starts closing the container just after a write has almost finished - after the write call to the FileChannel but before iosInProgress is decremented. So, it seems mostly harmless. Maybe moving the committedDropState check to the start of writePage and skipping the write altogether if it is in that state is a good approach? Any insight would be appreciated. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-v4.patch
Thanks again for your review and comments, Knut Anders, I appreciate it. Sorry for the long delay, but I've gotten busy with my autumn project - incidentally it's related to your work on DERBY-1704. =)
Now, you've convinced me regarding updatePageArray, I've removed it from the patch. =)
Regarding writePage() while the container is in the committedDrop state, I think it can happen in two cases: Somebody's writing to the container without obeying the lock protocols in Derby - or the cache is cleaning out dirty pages it is holding to the container.
According to BaseDataFileFactory#dropContainer(), the Container is locked in container exclusive mode while it is being closed and dropped. I haven't investigated the cache to see if it checks any such locks, but I presume it relies on it's clients to have the appropriate locks before writing to the container through the cache.
Since the original check for the commited drop state just makes writes to a committed dropped container a noop, I figure we can do that if somebody races in and closes the container between the first check and the actual write as well - so I've added a little exception handling which hopefully does the Right Thing. Comments or better suggestions welcome, of course.
So, here we go, DERBY-801-v4.patch. Hit it. Both storeall and encryptionAll passed before I added the exception handling mentioned above, and storeall passed just great on the attached patch as well. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443338 ]
Anders Morken commented on DERBY-801:
-------------------------------------
Yeah, looks like I've let in some critters. I'll give it a bit of a kickin' and see if I can figure it out. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: NIO-RAFContainer-v1.patch
NIO-RAFContainer-v1.patch is an experimental patch using the java.nio (New IO) framework to perform concurrent reads and writes to the same file without mutual exclusion. It passes storeall for me with Sun Java 1.4.2_09 on Linux, but needs some cleanup and refinement - and I don't even know if it actually helps performance yet. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Attachments: NIO-RAFContainer-v1.patch
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-v2.patch
DERBY-801-v2.patch is what I've got now. It's not anything very new since the previous patch, but it's a bit cleaner - and I've spent a lot of time pondering if what I've done here is safe. I think it mostly is. I'm sorry this has taken such an awful lot of time - I've been very busy with my day job this summer, and I haven't really had the time to sit down and do any proper work on this. Anyway, except for number 2. in my comment above, I think I've mostly addressed what I worried most about in the last patch. I'd appreciate any comments and suggestions for further improvement on this one. It passes storeall except for store/TransactionTable.sql which also fails in a clean trunk checkout. Thanks! =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12446493 ]
Anders Morken commented on DERBY-801:
-------------------------------------
> Maybe moving the committedDropState check to the start of writePage and skipping the write altogether if it is in that state is a good approach?
Never mind my ramblings, we already do that. OK, maybe we could check the committedDropState in the (iosInProgress == 0) assertion in closePage as well? All of this mess (iosInProgress and the associated assertions) is intended as a sanity checking aid, and if we agree that closing a container that is being dropped while IO is still active on it is sane, it shouldn't be a source of noise.
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (DERBY-801) Allow parallel access to data files.
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Mike Matrigali <mi...@sbcglobal.net> writes:
> One can assume jdk 1.4 or higher in the trunk, it was agreed to
> deprecate jdk1.3 starting with then next release (likely to be
> called 10.3). Of course, do not backport any such change to 10.2
> or before.
How does this affect J2ME? Are most of the jdk 1.4 features supported,
like FileChannel for this particular issue?
--
Knut Anders
Re: [jira] Resolved: (DERBY-801) Allow parallel access to data files.
Posted by Mike Matrigali <mi...@sbcglobal.net>.
One can assume jdk 1.4 or higher in the trunk, it was agreed to
deprecate jdk1.3 starting with then next release (likely to be
called 10.3). Of course, do not backport any such change to 10.2
or before.
Anders Morken (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
>
> Anders Morken resolved DERBY-801.
> ---------------------------------
>
> Resolution: Fixed
>
> OK, I'm marking this one as resolved, then. I've logged DERBY-2086 to remind us to look into some kind of resource pooling mechanism for encryption buffers and similar. I guess this isn't the only place where a pooling mechanism could be useful, so I intentionally worded it in a generic fashion.
>
> Regarding enhancing the StorageFactory interfaces to support general parallel access, I'm not sure I understand Suresh's intention completely. Implementing support for concurrent IO is specific to the different container types - and it may not even be feasible for compressed containers that require on decompression for seeks. Suresh, maybe you could explain it in a new Jira issue? ;-)
>
> As I considered earlier, we could enhance the StorageRandomAccessFile interface to add getChannel() support, but even that would apply only to random access files backed by real files that do support getChannel - and we'd have to throw in some JVM-dependent trickery as well, since getChannel() in RandomAccessFile only exists in Java 1.4+. (What's the timeframe on deprecating 1.3 support? I guess it could be a while? =)
>
> Anyway, thanks to everyone who helped me on this one. =)
>
>
>>Allow parallel access to data files.
>>------------------------------------
>>
>> Key: DERBY-801
>> URL: http://issues.apache.org/jira/browse/DERBY-801
>> Project: Derby
>> Issue Type: Improvement
>> Components: Performance, Store
>> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
>> Environment: Any
>> Reporter: Øystein Grøvlen
>> Assigned To: Anders Morken
>> Fix For: 10.3.0.0
>>
>> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>>
>>
>>Derby currently serializes accesses to a data file. For example, the
>>implementation of RAFContainer.readPage is as follows:
>> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
>> fileData.seek(pageOffset); // fileData is a RandomAccessFile
>> fileData.readFully(pageData, 0, pageSize);
>> }
>>I have experiemented with a patch where I have introduced several file
>>descriptors (RandomAccessFile objects) per RAFContainer. These are
>>used for reading. The principle is that when all readers are busy, a
>>readPage request will create a new reader. (There is a maximum number
>>of readers.) With this patch, throughput was improved by 50% on
>>linux. For more discussion on this, see
>>http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
>>The challenge with the suggested approach is to make a mechanism to
>>limit the number of open file descpriptors. Mike Matrigali has
>>suggested to use the existing CacheManager infrastructure for this
>>purpose. For a discussion on that, see:
>>http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
>
>
Re: [jira] Resolved: (DERBY-801) Allow parallel access to data files.
Posted by Suresh Thalamati <su...@gmail.com>.
Anders Morken (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
>
> Anders Morken resolved DERBY-801.
> ---------------------------------
>
> Resolution: Fixed
>
> OK, I'm marking this one as resolved, then. I've logged DERBY-2086 to remind us to look into some kind of
> resource pooling mechanism for encryption buffers and similar.
> I guess this isn't the only place where a pooling mechanism could be useful,
> so I intentionally worded it in a generic fashion.
>
> Regarding enhancing the StorageFactory interfaces to support general parallel access, I'm not sure I
> understand Suresh's intention completely. Implementing support for concurrent IO is specific to the
> different container types - and it may not even be feasible for compressed containers that require on
> decompression for seeks. Suresh, maybe you could explain it in a new Jira issue? ;-)
>
> As I considered earlier, we could enhance the StorageRandomAccessFile interface to add
> getChannel() support, but even that would apply only to random access files backed by real files
> that do support getChannel - and we'd have to throw in some JVM-dependent trickery as well,
> since getChannel() in RandomAccessFile only exists in Java 1.4+.
> (What's the timeframe on deprecating 1.3 support? I guess it could be a while? =)
>
Not sure when I made such a generic statement about storage factory
parallel access support, sorry if I had confused you. One thing I
wanted to work is if some one replaces the storage factory with
another implementation, new readPage/WritePage you added gets executed
instead of the old ones that allowed only single read/write of a
container file at a time.
I think we both are talking the same thing , As you say all that might
be needed is to add getChannel() method to the StorageRandomAccessFile
Interface and use it it in the RafContainer4.java instead of checking
for fileData is an instanceof java.io.RandomAccessFile.
Thanks
-suresh
[jira] Resolved: (DERBY-801) Allow parallel access to data files.
Posted by "Anders Morken (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken resolved DERBY-801.
---------------------------------
Resolution: Fixed
OK, I'm marking this one as resolved, then. I've logged DERBY-2086 to remind us to look into some kind of resource pooling mechanism for encryption buffers and similar. I guess this isn't the only place where a pooling mechanism could be useful, so I intentionally worded it in a generic fashion.
Regarding enhancing the StorageFactory interfaces to support general parallel access, I'm not sure I understand Suresh's intention completely. Implementing support for concurrent IO is specific to the different container types - and it may not even be feasible for compressed containers that require on decompression for seeks. Suresh, maybe you could explain it in a new Jira issue? ;-)
As I considered earlier, we could enhance the StorageRandomAccessFile interface to add getChannel() support, but even that would apply only to random access files backed by real files that do support getChannel - and we'd have to throw in some JVM-dependent trickery as well, since getChannel() in RandomAccessFile only exists in Java 1.4+. (What's the timeframe on deprecating 1.3 support? I guess it could be a while? =)
Anyway, thanks to everyone who helped me on this one. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Fix For: 10.3.0.0
>
> Attachments: DERBY-801-6.patch, DERBY-801-7.patch, DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch, NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira