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

Avoid spinlock in TimerStats



    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Done
    • None
    • 3.1.8
    • Concurrency
    • None
    • Fully Compatible
    • ALL
    • QuInt 8 08/28/15


      As we saw in SERVER-20091, using a spinlock in situations where a large number of threads can contend for a resource can lead to scalability issues and erratic behavior. Code inspection reveals an additional place where this might occur: TimerStats uses a spinlock to make updates to the count and the total time atomic, and this is used by gleWtimeStats, which can potentially be updated by a large number of threads at high connection count. We could avoid this by

      • using a mutex instead of a spinlock
      • don't use any lock, use atomics for the individual stats (count and total milliseconds), accept the possibility of a small skew between the two. I think this is probably acceptable for the typical uses of this statistic.

      I haven't been able to demonstrate a performance issue for this because this stat is only update for write concern with w>1 or j:true, and both of those have other performance issues that dominate at the moment. Independent of that however, it seems like a good idea to forestall performance pitfalls for future uses of this class.


        Issue Links



              martin.bligh Martin Bligh
              bruce.lucas@mongodb.com Bruce Lucas (Inactive)
              0 Vote for this issue
              7 Start watching this issue