db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Releasing latches when waiting for locks. When and why?
Date Mon, 20 Nov 2006 22:22:48 GMT
Mike Matrigali <mikem_app@sbcglobal.net> writes:

> Anders Morken wrote:
>> Mike Matrigali:
>>> Having said that it would be interesting if someone had time to
>>> implement a higher performance latch implementation and plug it in
>>>and see how much it helps.  It would decrease the total time spent
>>>in lock manager.
>> We've actually considered doing that for fun, but as our goal right now
>> is to produce a big honkin' report, not fix anything, we haven't. Still,
>> it would probably give a quite significant benefit.
>> Using a Java profiler on a reasonably modern X86 system we've found that
>> while acquiring a Derby lock takes about 60-70 microseconds and a latch
>> costs 50-60 microseconds in the non-contended (single thread) cases,
>> acquiring and releasing a ReentrantLock available in Java 1.5 and up
>> costs about 1,5 microseconds. A latch could in theory be about as cheap
>> as a ReentrantLock, and on Java 1.5 and up it would make sense to base
>> Latches on ReentrantLocks.
> Do you have something to compare these numbers to.  Maybe compared to
> the overall cost of Derby inserting a single row (not comitting), on
> the same machine.  Basically would be interested in what is the current
> locking overhead in cpu cost per some standard statement/xact.  I think
> when I looked at this awhile back locking/latching together was
> somewhere around 5% of
> a TPC/B like xact.  Given that, making locking 0 would only give a 5%
> improvement, so never was that motivated to look at latching.  But
> maybe other parts of the system/JVM have raised the ratio.

I did one experiment where I short-circuited all the methods in
SinglePool (had to keep some of the callback logic in order to keep
StoredPage happy) and ran some tests with read-only load using the
test client attached to DERBY-1961. With one client, I saw 20%
increase in throughput. Also, the CPU numbers Kristian posted at
http://wiki.apache.org/db-derby/Derby1961ResourceUsage2 indicate that
the lock manager has considerably more overhead than 5% for some types
of load. Note that his numbers include the network server cost, so for
embedded Derby the relative numbers would probably be even higher.

Knut Anders

View raw message