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 Mon, 14 Nov 2005 08:59:28 GMT
     [ http://issues.apache.org/jira/browse/DERBY-704?page=all ]

Knut Anders Hatlen updated DERBY-704:
-------------------------------------

    Attachment: DERBY-704.diff
                derbyall_report.txt

Attached patch and report from running derbyall (no tests failed).

The patch modifies the search for a free slot in the page cache
(org.apache.derby.impl.services.cache.Clock.findFreeItem()) in the
following way:

  1) find out how many invalid pages there are in the page cache
  2) check whether pages that are skipped in the search are invalid
  3) if the number of skipped invalid pages equals the number of
     invalid pages, stop the search for invalid pages

Could someone please review the patch? Thanks.

> 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: 10.1.2.2, 10.1.3.0, 10.2.0.0, 10.1.2.1, 10.1.2.0, 10.1.1.2, 10.1.1.1, 10.1.1.0
>  Environment: All platforms
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen
>      Fix For: 10.2.0.0
>  Attachments: DERBY-704.diff, 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message