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] Updated: (DERBY-704) Large page cache kills initial performance
Date Wed, 16 Nov 2005 13:36:29 GMT
     [ http://issues.apache.org/jira/browse/DERBY-704?page=all ]

Knut Anders Hatlen updated DERBY-704:

    Attachment: DERBY-704-extra-comments.diff

Patch DERBY-704-extra-comments.diff adds the following comments
to the code:

  // 1) find out how many invalid items there are in the
  //    cache
  // 2) search for a free invalid item
  // 3) stop searching when there are no more invalid
  //    items to find


  // Invalid items might occur in the cache when
  //   a) a new item is created in growCache(), but it
  //      is not in use yet, or
  //   b) an item is deleted (usually when a table is
  //      dropped)

  // It is critical to break out of the loop as soon as
  // possible since we are blocking others trying to
  // access the page cache. New items are added to the
  // end of the page cache, so the search for invalid
  // items should start from the end.

If the comments are OK, could a committer please commit this change?


svn stat:

M      java/engine/org/apache/derby/impl/services/cache/Clock.java

> Large page cache kills initial performance
> ------------------------------------------
>          Key: DERBY-704
>          URL: http://issues.apache.org/jira/browse/DERBY-704
>      Project: Derby
>         Type: Bug
>   Components: Services, Performance
>     Versions:,,,,,,,
>  Environment: All platforms
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen
>      Fix For:
>  Attachments: DERBY-704-extra-comments.diff, DERBY-704.diff, cpu-usage.png, derbyall_report.txt,
> When the page cache is large the performance gets lower as the page
> cache is being filled. As soon as the page cache is filled, the
> throughput increases. In the period with low performance, the CPU
> usage is high, and when the performance increases the CPU usage is
> lower.
> This behaviour is caused by the algorithm for finding free slots in
> the page cache. If there are invalid pages in the page cache, it will
> be scanned to find one of those pages. However, when multiple clients
> access the database, the invalid pages are often already taken. This
> means that the entire page cache will be scanned, but no free invalid
> page is found. Since the scan of the page cache is synchronized on the
> cache manager, all other threads that want to access the page cache
> have to wait. When the page cache is large, this will kill the
> performance.
> When the page cache is full, this is not a problem, as there will be
> no invalid pages.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message