[ http://issues.apache.org/jira/browse/DERBY-1704?page=comments#action_12434366 ] Anders Morken commented on DERBY-1704: --------------------------------------
While I don't know exactly what indications you've seen of the lock contention in the lock manager, we've seen the exact same thing in our investigations in our "SMP scalability in Derby" project. (We == me and Per Ottar Ribe Pahr). Anyway, we used DTrace with a JDK1.6 beta release to measure monitor contention in a simple embedded derby scenario consisting of 8 threads doing simple "SELECT A FROM FOO WHERE A=?; COMMIT;" loops. FOO is a table consisting of about 100 000 rows of A, an integer and the primary key, and a CHAR(96) FOR BIT DATA filler. The dtrace script measured three things: The classes of objects whose monitors were most contented - in terms of number of contentions and the wait time threads spent waiting for their monitors. In addition, it took a snapshot of the call stack at the point of contention to figure out which method the contention occured in. Here's our measurements, we hope they're useful, if only to confirm that you're onto something. =) PS: You want a fixed-point font to read this. Point your web browser at http://folk.ntnu.no/andersmo/monitor_contention.txt to get a plain old text file. =) TOP BLOCKING OBJECTS: Monitor class Contention count org/apache/derby/impl/services/locks/ActiveLock 2 java/lang/ref/ReferenceQueue$Lock 2 org/apache/derby/impl/services/cache/CachedItem 2 org/apache/derby/impl/services/reflect/ReflectLoaderJava2 3 java/io/PrintStream 5 org/apache/derby/impl/store/raw/data/StoredPage 10 sun/misc/Launcher$AppClassLoader 10 org/apache/derby/impl/sql/GenericPreparedStatement 10 org/apache/derby/impl/store/raw/xact/XactFactory 11 org/apache/derby/impl/store/raw/xact/TransactionTable 29 java/util/Hashtable 34 org/apache/derby/impl/store/raw/data/AllocationCache 36 org/apache/derby/impl/services/cache/Clock 257 org/apache/derby/impl/services/locks/SinglePool 577 org/apache/derby/impl/services/locks/LockSet 7851 TOP BLOCKING OBJECTS BY WAIT TIME: Monitor class Wait time (ms) java/lang/ref/ReferenceQueue$Lock 2 org/apache/derby/impl/services/locks/ActiveLock 2 org/apache/derby/impl/services/cache/CachedItem 6 org/apache/derby/impl/store/raw/data/StoredPage 11 org/apache/derby/impl/services/reflect/ReflectLoaderJava2 13 org/apache/derby/impl/store/raw/data/AllocationCache 110 org/apache/derby/impl/sql/GenericPreparedStatement 120 org/apache/derby/impl/store/raw/xact/TransactionTable 129 java/util/Hashtable 198 org/apache/derby/impl/store/raw/xact/XactFactory 350 sun/misc/Launcher$AppClassLoader 660 java/io/PrintStream 709 org/apache/derby/impl/services/cache/Clock 1380 org/apache/derby/impl/services/locks/SinglePool 3137 org/apache/derby/impl/services/locks/LockSet 16194 TOP BLOCKING METHOD SIGNATURES: org/apache/derby/impl/services/locks/LockSet.lockObject(Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks/Lockable;Ljava/l ang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock;* 55 org/apache/derby/impl/services/cache/Clock.find(Ljava/lang/Object;)Lorg/apache/derby/iapi/services/cache/Cacheable;* 56 org/apache/derby/impl/services/locks/LockSet.lockObject(Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks/Lockable;Ljava/l ang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock;* 56 org/apache/derby/impl/services/cache/Clock.release(Lorg/apache/derby/iapi/services/cache/Cacheable;)V* 65 org/apache/derby/impl/services/locks/SinglePool.lockAnObject(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/derby/iapi/services /locks/Lockable;Ljava/lang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock;* 79 java/util/Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object;* 84 org/apache/derby/impl/services/locks/SinglePool.unlock(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks /Lockable;Ljava/lang/Object;)I 85 org/apache/derby/impl/services/locks/SinglePool.lockObject(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/derby/iapi/services/l ocks/Lockable;Ljava/lang/Object;I)Z 103 org/apache/derby/impl/services/locks/LockSpace.unlockGroup(Lorg/apache/derby/impl/services/locks/LockSet;Ljava/lang/Object;)V 110 org/apache/derby/impl/services/locks/LockSet.unlock(Lorg/apache/derby/iapi/services/locks/Latch;I)V* 153 java/util/Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object;* 221 org/apache/derby/impl/services/locks/SinglePool.lockAnObject(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/derby/iapi/services /locks/Lockable;Ljava/lang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock; 260 org/apache/derby/impl/services/locks/SinglePool.unlatch(Lorg/apache/derby/iapi/services/locks/Latch;)V 264 org/apache/derby/impl/services/locks/SinglePool.unlock(Ljava/lang/Object;Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks /Lockable;Ljava/lang/Object;)I 330 org/apache/derby/impl/services/locks/SinglePool.latchObject(Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks/Lockable;Lja va/lang/Object;I)Z 459 org/apache/derby/impl/services/locks/LockSet.lockObject(Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks/Lockable;Ljava/l ang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock;* 559 org/apache/derby/impl/services/locks/LockSet.unlock(Lorg/apache/derby/iapi/services/locks/Latch;I)V* 1714 org/apache/derby/impl/services/locks/LockSet.lockObject(Ljava/lang/Object;Lorg/apache/derby/iapi/services/locks/Lockable;Ljava/l ang/Object;ILorg/apache/derby/iapi/services/locks/Latch;)Lorg/apache/derby/impl/services/locks/Lock;* 2840 > 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
