You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org> on 2006/08/16 14:34:14 UTC
[jira] Updated: (DERBY-1704) Allow more concurrency in the lock
manager
[ http://issues.apache.org/jira/browse/DERBY-1704?page=all ]
Knut Anders Hatlen updated DERBY-1704:
--------------------------------------
Attachment: 1cpu.png
2cpu.png
8cpu.png
Just to see how the performance would be affected if the global
synchronization points were eliminated, I split the hash tables in
SinglePool and LockSet into 16 partitions (that is, 16 hash tables),
and used the hash key to decide which partition an object should be
placed in. There was no global synchronization, only synchronization
on the partition.
I have attached graphs for some performance tests with single-record
selects (the entire database was in the page cache). The graphs show
the results on a machine with a single CPU (1cpu.png), one with two
CPUs (2cpu.png) and one with eight CPUs (8cpu.png). They indicate that
there is no significant effect (neither positive nor negative) on the
single-CPU machine, but with multiple CPUs (and multiple threads) the
performance increases when the global synchronization points have been
eliminated.
(Don't pay too much attention to the actual TPS numbers, since the
three machines didn't have identical processors.)
> 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.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
> Attachments: 1cpu.png, 2cpu.png, 8cpu.png
>
>
> 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