[ http://issues.apache.org/jira/browse/DERBY-1704?page=comments#action_12434378 ] Anders Morken commented on DERBY-1704: --------------------------------------
Oh, forgot to mention that the tests were run on a SMP machine - an old Sun Enterprise 450 with 4x400MHz CPUs (and a bit error on bit 12 on memory module 1701 - yay ECC. ;-). The Derby release used was 10.1.3.1 - (417277), the official release from the web page. If time permits we'll see about testing Knut Anders' patch with DTrace as well. > Allow more concurrency in the lock manager > ------------------------------------------ > > Key: DERBY-1704 > URL: http://issues.apache.org/jira/browse/DERBY-1704 > Project: Derby > Issue Type: Improvement > Components: Services, Performance > Affects Versions: 10.2.1.0 > Reporter: Knut Anders Hatlen > Priority: Minor > Attachments: 1cpu.png, 2cpu.png, 8cpu.png, split-hashtables.diff, > split-hashtables.stat > > > I have seen indications of severe monitor contention in SinglePool > (the current lock manager) when multiple threads access a Derby > database concurrently. When a thread wants to lock an object, it needs > to obtain the monitor for both SinglePool and LockSet (both of them > are global synchronization points). This leads to poor scalability. > We should investigate how to allow more concurrency in the lock > manager, and either extend SinglePool or implement a new manager. -- 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
