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

Mime
View raw message