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