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

Hang on shutdown with a busy cache pool

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • WT2.9.2, 3.2.13, 3.4.3, 3.5.4
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage 2017-03-06

      Our jenkins test detected a hang when shutting down a run of ../bench/wtperf/stress//shared-cache-stress.wtperf, the hang showed a thread was adjusting the pool:

      Thread 22 (Thread 0x7f2e0cff9700 (LWP 129430)):
      #0  0x000000000041b97f in __cache_pool_adjust (session=0x7f2e280174f0, highest=3487, bump_threshold=0, forward=true, adjustedp=0x7f2e0cff8eff)
          at ../src/conn/conn_cache_pool.c:573
      #1  0x000000000041b4c6 in __cache_pool_balance (session=0x7f2e280174f0, forward=true) at ../src/conn/conn_cache_pool.c:446
      #2  0x000000000041c035 in __wt_cache_pool_server (arg=0x7f2e280174f0) at ../src/conn/conn_cache_pool.c:758
      #3  0x0000003e6ce07555 in start_thread () from /lib64/libpthread.so.0
      #4  0x0000003e6cb02ded in clone () from /lib64/libc.so.6

      In the debugger it became clear that the in-use proportion of the pool was never being adjusted, so the __cache_pool_balance call was never completing, which meant that destroy could not get the cache pool spin lock and would end up hanging.

            alexander.gorrod@mongodb.com Alexander Gorrod
            alexander.gorrod@mongodb.com Alexander Gorrod
            0 Vote for this issue
            1 Start watching this issue