[
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: 10.4.0.0
> 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.
