[ http://issues.apache.org/jira/browse/DERBY-704?page=comments#action_12357574 ]
Knut Anders Hatlen commented on DERBY-704: ------------------------------------------ Sorry, I forgot the output from 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: 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, > 10.1.3.0, 10.1.2.2 > Environment: All platforms > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Fix For: 10.2.0.0 > Attachments: DERBY-704.diff, cpu-usage.png, derbyall_report.txt, > throughput.png > > 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