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] Updated: (DERBY-2327) Reduce monitor contention in LockSet
Date Fri, 23 Mar 2007 09:12:32 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-2327:
--------------------------------------

    Attachment: niagara-select.png
                8cpu-select.png
                2cpu-select.png

I'm attaching some throughput graphs to give an impression of the
effect of the 4a patch. I have used the DERBY-1961 test client with
single-record select load (primary key), 1 to 70 concurrent clients,
running embedded Derby with all data in the page cache. The graphs
show the throughput for trunk and the patched version of trunk with
JDK5 and JDK6. I have run the tests on three different machines: one
dual CPU Opteron, one machine with 8 CPUs, and one Niagara with 8
cores and 32 hardware threads. All the test machines were running
Solaris 10.

With the exception of JDK6 on the dual Opteron machine, all the tests
show improved throughput with multiple clients. They don't show any
significant reduction in throughput in the single-user case.

> Reduce monitor contention in LockSet
> ------------------------------------
>
>                 Key: DERBY-2327
>                 URL: https://issues.apache.org/jira/browse/DERBY-2327
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Performance, Services
>    Affects Versions: 10.3.0.0
>            Reporter: Knut Anders Hatlen
>         Assigned To: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: 2cpu-select.png, 8cpu-select.png, ConcurrentHashMap.diff, derby-2327-1a.diff,
derby-2327-1a.stat, derby-2327-2a.diff, derby-2327-2a.stat, derby-2327-3a.diff, derby-2327-4a.diff,
derby-2327-4a.stat, niagara-select.png
>
>
> When multiple threads enter the lock manager, only one can access the hash table in LockSet.
To improve scalability on multiple CPUs, it should be possible to have more than one thread
accessing the lock table at the same time.

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


Mime
View raw message