db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anders Morken (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-801) Allow parallel access to data files.
Date Fri, 26 May 2006 22:07:31 GMT
    [ 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


Mime
View raw message