Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2013293614.1134729347358.JavaMail.jira@ajax.apache.org>
Date: Fri, 16 Dec 2005 11:35:47 +0100 (CET)
From: "Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-733) Starvation in RAFContainer.readPage()
In-Reply-To: <1924988682.1133366610352.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-733?page=all ]

Knut Anders Hatlen updated DERBY-733:
-------------------------------------

    Attachment: Insert.java
                Select.java

I have attached a test case that makes it possible to reproduce the
reported issue. There are two files:

* Insert.java:

   Creates a database "mydb" in the current directory and fills it
   with about five gigabytes of data. (If you have more than 1 GB of
   RAM, you might consider increasing the database size since some
   operating systems use all available main memory for file system
   caching, and then you won't be testing disk accesses.) The database
   consists of one table with two columns:

     (id int primary key, text char(100))

   The command "java Insert" will start the program.

* Select.java:

   Start the program with "java Select <clients> <seconds>", where
   <clients> is the number of clients you want to test and <seconds>
   is the number of seconds the test will run. The program will start
   as many clients as requested, and each client will repeatedly
   select a random row from the table generated by the Insert
   program. Every ten seconds the progress of each client is printed
   (number of transactions in the last ten seconds). When the test has
   finished, it prints the throughput and the avg/min/max response
   time.

I have run this test (40 clients/10 minutes) on Linux 2.6.14 with the
following results (this is NOT a benchmark):

  Before revision 356884 was committed:

     Sun JVM 1.4.2: 78.3 tps /    727 ms max resp
     IBM JVM 1.4.2: 78.2 tps /   1079 ms max resp
   Blackdown 1.4.2: 78.9 tps /    717 ms max resp
     Sun JVM 1.5.0: 78.2 tps / 609483 ms max resp
     IBM JVM 1.5.0: Went into infinite loop because of I/O error

  After revision 356884 was committed:

     Sun JVM 1.4.2: 78.7 tps /  690 ms max resp
     IBM JVM 1.4.2: 78.1 tps / 1080 ms max resp
   Blackdown 1.4.2: 79.3 tps /  656 ms max resp
     Sun JVM 1.5.0: 79.1 tps /  682 ms max resp
     IBM JVM 1.5.0: Went into infinite loop because of I/O error

> 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.1.2.1, 10.2.0.0, 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, Insert.java, Select.java
>
> 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