db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-733) Starvation in RAFContainer.readPage()
Date Wed, 14 Dec 2005 22:30:54 GMT
It would be interesting to know the actual performance difference 
between using the java lock call and a lock manager latch.  Using the
latch would mean that we would get the same performance benefit on
jdk1.4 as well.

As I said, it would nice if you submitted your worst case test -- even
if it is not appropriate as a nightly unit test.  That way derby users
could run it against a variety of hardware, OS's and JVM's.  Something
simple to show the problem you are fixing like a single big table, many
threads accessing more pages than fit in cache.

I also
have wondered at what cost to btree performance is the current use
of lock manager based latches vs. something closer than a test/set
of bit on page.  We do get a benefit in that latch/lock deadlocks are
reported correctly by the derby lock manager, which is not possible
once you introduce a different locking mechanism.

Do note that I believe in a different thread it was argued that adding
this new lock was ok as the performance did not matter that much 
compared to the I/O cost of the read.

Øystein Grøvlen (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-733?page=comments#action_12360454 ]

> 
> Øystein Grøvlen commented on DERBY-733:
> ---------------------------------------
> 
> It is possible to use the lock manager for a lock that is local to the object?  I do
not think it is a good idea to enter the lock into the general lock pool.  That seems like
quite a lot of unnecessary overhead.  
> 
> I also think that in the long run we should consider replacing the current latches with
the built-in locks provided by Java.
> 
> 
> 
>>Starvation in RAFContainer.readPage()
>>-------------------------------------
>>
>>         Key: DERBY-733
>>         URL: http://issues.apache.org/jira/browse/DERBY-733
>>     Project: Derby
>>        Type: Improvement
>>  Components: Performance, Store
>>    Versions: 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2
>> Environment: Solaris x86 and Linux with Sun JVM 1.5.0. Derby embedded and client/server.
>>    Reporter: Knut Anders Hatlen
>>    Assignee: Knut Anders Hatlen
>> Attachments: DERBY-733.diff
>>
>>When Derby is completely disk bound, threads might be starved in
>>RAFContainer.readPage(). This is a real problem when multiple clients
>>are repeatedly accessing one or a small number of large tables. In
>>cases like this, I have observed very high maximum response times
>>(several minutes in the worst cases) on simple transactions. The
>>average response time is not affected by this.
>>The starvation is caused by a synchronized block in
>>RAFContainer.readPage():
>>  synchronized (this) {
>>      fileData.seek(pageOffset);
>>      fileData.readFully(pageData, 0, pageSize);
>>  }
>>If many threads want to read pages from the same file, there will be a
>>long queue of threads waiting for this monitor. Since the Java
>>specification does not guarantee that threads waiting for monitors are
>>treated fairly, some threads might have to wait for a long time before
>>they get the monitor. (Usually, a couple of threads get full throughput
>>while the others have to wait.)
> 
> 


Mime
View raw message