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

Avoid spinlock in TimerStats

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.8
    • Component/s: Concurrency
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      QuInt 8 08/28/15

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: