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

Creating 10-20 new eviction threads per second

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT2.7.0
    • Labels:
      None
    • # Replies:
      3
    • Last comment by Customer:
      true

      Description

      Observed in mongod 3.0.5 and 3.1.5. Here's the stack trace from mongod 3.1.5:

      Breakpoint 1, __pthread_create_2_1 (newthread=0x2bd6250, attr=attr@entry=0x0, start_routine=start_routine@entry=0x13d4cd0 <__evict_worker>, arg=0x2bd6240) at pthread_create.c:466
      466	in pthread_create.c
      (gdb) bt
      #0  __pthread_create_2_1 (newthread=0x2bd6250, attr=attr@entry=0x0, start_routine=start_routine@entry=0x13d4cd0 <__evict_worker>, arg=0x2bd6240) at pthread_create.c:466
      #1  0x00000000013efd34 in __wt_thread_create (session=session@entry=0x2f00300, tidret=<optimized out>, func=func@entry=0x13d4cd0 <__evict_worker>, arg=<optimized out>)
          at src/third_party/wiredtiger/src/os_posix/os_thread.c:22
      #2  0x00000000013d51c1 in __evict_pass (session=0x2f00300) at src/third_party/wiredtiger/src/evict/evict_lru.c:518
      #3  __evict_server (arg=0x2f00300) at src/third_party/wiredtiger/src/evict/evict_lru.c:170
      #4  0x00007fdd81528182 in start_thread (arg=0x7fdd80690700) at pthread_create.c:312
      #5  0x00007fdd8125547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
      

        Issue Links

          Activity

          Hide
          alexander.gorrod Alexander Gorrod added a comment -

          Bruce Lucas Eviction server threads starting and stopping isn't a sign of a failure. Threads are started and stopped as more or less eviction is required. The algorithm to determine how many threads are needed is currently too sensitive - which leads to the behavior you have observed.

          Fixing it is on our TODO list, but hasn't crept to the top since we haven't observed any user visible effect.

          Show
          alexander.gorrod Alexander Gorrod added a comment - Bruce Lucas Eviction server threads starting and stopping isn't a sign of a failure. Threads are started and stopped as more or less eviction is required. The algorithm to determine how many threads are needed is currently too sensitive - which leads to the behavior you have observed. Fixing it is on our TODO list, but hasn't crept to the top since we haven't observed any user visible effect.
          Hide
          xgen-internal-githook Githook User added a comment -

          Author:

          {u'username': u'agorrod', u'name': u'Alex Gorrod', u'email': u'alexg@wiredtiger.com'}

          Message: WT-2017 Don't shutdown eviction server threads during runtime.

          Once there has been enough workload for threads to be started leave
          them running. Stopping/starting is expensive and distracting in a
          debugger.
          Branch: develop
          https://github.com/wiredtiger/wiredtiger/commit/9ee52301725f1e760e74f01e85184554b86e7b35

          Show
          xgen-internal-githook Githook User added a comment - Author: {u'username': u'agorrod', u'name': u'Alex Gorrod', u'email': u'alexg@wiredtiger.com'} Message: WT-2017 Don't shutdown eviction server threads during runtime. Once there has been enough workload for threads to be started leave them running. Stopping/starting is expensive and distracting in a debugger. Branch: develop https://github.com/wiredtiger/wiredtiger/commit/9ee52301725f1e760e74f01e85184554b86e7b35
          Hide
          alexander.gorrod Alexander Gorrod added a comment -

          Merged into develop branch.

          Show
          alexander.gorrod Alexander Gorrod added a comment - Merged into develop branch.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                1 year, 34 weeks, 5 days ago
                Date of 1st Reply: