db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-733) Starvation in RAFContainer.readPage()
Date Wed, 30 Nov 2005 16:03:30 GMT
Starvation in RAFContainer.readPage()
-------------------------------------

         Key: DERBY-733
         URL: http://issues.apache.org/jira/browse/DERBY-733
     Project: Derby
        Type: Bug
  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
 Assigned to: Knut Anders Hatlen 


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


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message