Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-24194

Queued table drops within the WiredTiger KVEngine can compete with each other

    • Fully Compatible
    • ALL
    • Hide

      Run the test jstest/slow1/remove_during_mr.js on OSX or on Linux with strace instrumentation to slow system calls.

      Show
      Run the test jstest/slow1/remove_during_mr.js on OSX or on Linux with strace instrumentation to slow system calls.
    • 0

      Queued table drops within the WTKVEngine can compete with each other.

      When creating and dropping a large number of tables (such as running multiple concurrent map/reduce jobs) MongoDB creates a large number of tables then drops them in quick succession. Given that the instance is still "hot" at this point as there are multiple create and drop operations going on at once, many of these drops get queued to be dropped later.

      This queuing then triggers a close of all sessions and any number of threads will then enter the code path to drop all of the queued collections all starting at the top. Having multiple threads enter the drop code at once means that we often see several attempts to drop one collection(s) before a single drop succeeds, during which time further collection drops are often queued. This causes an almost quadratic case, where a high rate of collection creates/drops will cause more and more drops to be queued.

      One thing needed to create the conditions for this is a small level of delay in processing of the deletes. I suspect this occurs on OSX as we must use the slower fsync or with strace on linux - which slows the OS calls.

            Assignee:
            david.hows David Hows
            Reporter:
            david.hows David Hows
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: