Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5907

Linkbench regression in 4.4 after durable history was merged

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.4.0-rc7
    • Affects Version/s: None
    • Component/s: None
    • 5
    • Storage Engines 2020-04-06, Storage - Ra 2020-04-20, Storage - Ra 2020-05-04, Storage - Ra 2020-05-18

      The full report is here. Copying from the Summary...

      This has results for IO-bound Linkbench. By IO-bound I mean the database is much larger than RAM. Tests were run on a single-node replica in DSI. The database should be ~300G after the load. The load uses ~21 threads and transaction tests used 1, 16, 32 and 64 client threads.

      Results are provided for 4.0, 4.2 and two 4.4 builds. For 4.4 there is 4.4pre which is a recent 4.4 build prior to the durable history merge using this URL and then 4.4dh using this URL and git hash 00502b which is the first commit with durable history.

      Comparing 4.4dh with 4.4pre

      • 17% regression in the load rate for 4.4dh
      • ~20% regression in the transaction/second rates for 4.4dh
      • ~2X regression in mongod RSS for 4.4dh, this looks like a memory leak
      • 31% regression in the database size for 4.4dh

      The memory leak and disk space regressions are visible during the load.

      This test used the new (optimized) Linkbench client, called linkbench2 in DSI. BF-16496 is open for a regression in classic Linkbench, although that was run for a shorter time and with a smaller database and the memory leak and database size problems are easier to spot here.

        1. heap.mar24.metrics.2020-03-24T04-50-31Z-00000
          102 kB
          Mark Callaghan
        2. heap.mar24.metrics.2020-03-24T04-51-06Z-00000
          9.89 MB
          Mark Callaghan
        3. heap.mar24.metrics.2020-03-24T07-54-45Z-00000
          9.46 MB
          Mark Callaghan
        4. heap.mar24.mongod.log.2020-03-23T20-08-07
          86 kB
          Mark Callaghan
        5. heap.mar24.mongod.log.2020-03-23T21-19-27
          35 kB
          Mark Callaghan
        6. heap.mar24.mongod.log.2020-03-24T04-51-05
          102 kB
          Mark Callaghan
        7. heap.mar24.mongod.log.gz
          75.17 MB
          Mark Callaghan
        8. heap.png
          292 kB
          Bruce Lucas
        9. mo44dh.metrics.2020-03-19T15-13-30Z-00000
          44 kB
          Mark Callaghan
        10. mo44dh.metrics.2020-03-19T15-14-04Z-00000
          9.83 MB
          Mark Callaghan
        11. mo44dh.metrics.2020-03-19T19-47-11Z-00000
          4.37 MB
          Mark Callaghan
        12. mo44pre.metrics.2020-03-20T17-54-05Z-00000
          43 kB
          Mark Callaghan
        13. mo44pre.metrics.2020-03-20T17-54-39Z-00000
          9.87 MB
          Mark Callaghan
        14. mo44pre.metrics.2020-03-20T22-38-23Z-00000
          3.18 MB
          Mark Callaghan
        15. setp.mar28.metrics.2020-03-27T20-59-48Z-00000
          33 kB
          Mark Callaghan
        16. setp.mar28.metrics.2020-03-27T21-00-21Z-00000
          9.84 MB
          Mark Callaghan
        17. setp.mar28.metrics.2020-03-28T01-45-13Z-00000
          3.33 MB
          Mark Callaghan
        18. setp.mar28.mongod.log.2020-03-27T21-00-20
          35 kB
          Mark Callaghan
        19. setp.mar28.mongod.log.gz
          54.61 MB
          Mark Callaghan
        20. unable.png
          325 kB
          Bruce Lucas
        21. window.png
          173 kB
          Bruce Lucas

            Assignee:
            brian.lane@mongodb.com Brian Lane
            Reporter:
            mark.callaghan@mongodb.com Mark Callaghan (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: