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

CursorManager Lock is very hot

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.8
    • Affects Version/s: None
    • Component/s: Querying
    • None
    • Fully Compatible
    • Query 10 (02/22/16), Query 14 (05/13/16), Query 15 (06/03/16), Query 2017-03-27, Query 2017-04-17, Query 2017-05-08, Query 2017-05-29

      Under heavy load the cursor manager lock causes negative scalability. –
      on power8 firestone (2 socket, 20 cores, 160 hwtreads) running redhat 7.2, mongo 3.2-pre, 4 10Gig E's hard wired to another firestone running 4 copies of ycsb with between 64 and 400 threads each. Throughput peaks at the lower end (64 threads each on ycsb) and has negative scaling with the larger numbers. Tracing data and profile (from perf) information indicate that the bottleneck is on the cursor manager mutex lock. a prototype (read hack) replacing the mutex lock with a mongo spinlock increased peak performance from 240K ops to 320K ops and minimized the negative scaling

        1. mongoDBscaling.odp
          40 kB
          Jim Van Fleet
        2. profile.tar.gz
          11.35 MB
          Jim Van Fleet
        3. server21754_2.patch
          20 kB
          David Storch
        4. server21754.patch
          20 kB
          David Storch

            Assignee:
            charlie.swanson@mongodb.com Charlie Swanson
            Reporter:
            jvf Jim Van Fleet
            Votes:
            0 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: