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

Ignore evict priority for btrees that are dominating cache usage



    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 4.4.0-rc11
    • WT10.0.0, 4.4.1, 4.7.0
    • None
    • None
    • 8
    • Storage - Ra 2020-07-27, Storage - Ra 2020-08-10


      MongoDB instance with 1 GB cache; workload simple continuously creates collections with the default single _id index.

      • At A we begin doing evictions. Dirty fill ratio is small so this appears to be triggered by "bytes allocated for updates" reaching 25 MB or 2.5% of cache. Also disabling WT-6175 eliminates this behavior. Not sure though why this is triggered at 2.5% of cache - isn't the trigger value by default 10%?
      • At B it appears we no longer are able to evict the "bytes allocated for updates" and begin indefinitely burning 1 CPU apparently trying to evict content that can't be evicted. This occurs when we reach 6000 collections (12000 tables/files including the single index, 24000 handles). Dropping all the collections reduces open files to 0 but does not immediately reduce handles, and the eviction/cpu behavior continues, so the "bytes allocated for updates" that can't be evicted appears to be associated with handles, not files.

      This is related to WT-6420 but distinct from it as it looks like this issue is not specific to very small caches and can happen with any size cache and sufficient file handles.


        1. handles.png
          185 kB
        2. Screen Shot 2020-07-17 at 7.15.12 pm.png
          Screen Shot 2020-07-17 at 7.15.12 pm.png
          263 kB
        3. x-1GB-1.tar
          286 kB

        Issue Links



              alex.cameron@mongodb.com Alex Cameron (Inactive)
              bruce.lucas@mongodb.com Bruce Lucas
              0 Vote for this issue
              10 Start watching this issue