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.)
>
>
|