db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
Date Fri, 02 Nov 2007 13:03:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539575

Knut Anders Hatlen commented on DERBY-2911:

> Have you tried lifting restriction a), so that the background cleaner is allowed to clean
more than one page?

I ran a small experiment with the test client attached to DERBY-1961 (single-record update
transactions), but I couldn't see much difference between the runs which had a background
cleaner and those which didn't have one. I also tried to make the background cleaner write
10 pages instead of 1, but that didn't help either. Now, the DERBY-1961 test client uses a
relatively small DB (~10MB, I think), and since we don't sync after we write a page, I guess
most writes only go to the file system cache and are fairly quick. I could try to rerun the
experiment with a database that's much larger than the physical RAM and see if there's a noticeable
difference then.

> Is there a reason not to let the background cleaner re-queue itself?

Only if the background cleaner slows things down, but then it would be better to disable it
alltogether. :)

I think I'll just try to make the new background cleaner behave the same way as the old one
(or as close as possible) for now. If we find out later that the current behaviour is not
optimal, it shouldn't take much work to change it.

> Implement a buffer manager using java.util.concurrent classes
> -------------------------------------------------------------
>                 Key: DERBY-2911
>                 URL: https://issues.apache.org/jira/browse/DERBY-2911
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Services
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d2911-1.diff, d2911-1.stat, d2911-2.diff, d2911-3.diff, d2911-4.diff,
d2911-5.diff, d2911-6.diff, d2911-6.stat, d2911-7.diff, d2911-7a.diff, d2911-entry-javadoc.diff,
d2911-unused.diff, d2911-unused.stat, d2911perf.java, perftest6.pdf
> There are indications that the buffer manager is a bottleneck for some types of multi-user
load. For instance, Anders Morken wrote this in a comment on DERBY-1704: "With a separate
table and index for each thread (to remove latch contention and lock waits from the equation)
we (...) found that org.apache.derby.impl.services.cache.Clock.find()/release() caused about
5 times more contention than the synchronization in LockSet.lockObject() and LockSet.unlock().
That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer manager which
exploits the concurrency utilities added in Java SE 5.

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

View raw message