Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-704

Large page cache kills initial performance

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6
    • 10.1.3.1, 10.2.1.6
    • Services
    • None
    • All platforms
    • Performance

    Description

      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.

      Attachments

        1. DERBY-704.diff
          1 kB
          Knut Anders Hatlen
        2. derbyall_report.txt
          4 kB
          Knut Anders Hatlen
        3. cpu-usage.png
          7 kB
          Knut Anders Hatlen
        4. throughput.png
          7 kB
          Knut Anders Hatlen
        5. DERBY-704-extra-comments.diff
          1 kB
          Knut Anders Hatlen

        Activity

          People

            knutanders Knut Anders Hatlen
            knutanders Knut Anders Hatlen
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: