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

Investigate need for markThreadIdle with adaptive service executor

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.4, 3.7.1
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • v3.6
    • Platforms 2017-09-11, Platforms 2017-10-02, Platforms 2017-11-13, Platforms 2018-01-01, Platforms 2018-01-15

      Each of the six runs ramps up from 0 to 500 client threads each attempting to do as many as 1000 updates per second. The system reaches CPU saturation at about 38 k/s, so of course we expect to see queuing, and to see the client open 500 connections. The six runs are respectively

      1. synchronous, 3.5.11
      2. synchronous, 3.5.11 + SERVER-28599
      3. synchronous, 3.5.11 with calls to markThreadIdle suppressed
      4. adaptive, 3.5.11
      5. adaptive, 3.5.11 + SERVER-28599
      6. adaptive, 3.5.11 with calls to markThreadIdle suppressed

      Comparing runs 4, 5, and 6 we see the impact of markThreadIdle in 4 with the adaptive service executor, fixed by either change in 5 and 6.

      Once the current performance issue with markThreadIdle has been addressed by SERVER-28599, we should investigate whether and where markThreadIdle should be called in the adaptive case. This should be evaluated using the tests from SERVER-16773 that led to the implementation of markThreadIdle for the synchronous case.

            mark.benvenuto@mongodb.com Mark Benvenuto
            bruce.lucas@mongodb.com Bruce Lucas (Inactive)
            0 Vote for this issue
            10 Start watching this issue