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

eviction changes cost LSM performance

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • WT2.9.2, 3.2.13, 3.4.4, 3.5.6
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage 2017-03-27

      alexander.gorrod comments in WT-3199:

      This change introduced a significant performance regression on the parallel-pop-lsm wtperf job in Jenkins:

      michael.cahill noted in his review of the change:

      Hopefully the round trip to interrupt the eviction server every time we start a new LSM chunk won't be significant, but we've already talked about using an epoch in eviction rather than the locking we're currently doing in there.

      Obviously, it is significant.

      I'm hesitant to go back to what we were doing before (eviction could start a walk in a btree just before it was switched in to become primary), but we could probably make it safe.

      I'm happy to take a look at using epochs in eviction, rather than locking, or any other ideas anyone has. Is there anything written up on this yet?

            keith.bostic@mongodb.com Keith Bostic (Inactive)
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            0 Vote for this issue
            2 Start watching this issue