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

Avoid spinlock in TimerStats

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.1.8
    • Affects Version/s: None
    • Component/s: 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.

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

              Created:
              Updated:
              Resolved: