[SERVER-30609] Investigate need for markThreadIdle with adaptive service executor Created: 11/Aug/17 Updated: 30/Oct/23 Resolved: 04/Jan/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.4, 3.7.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Mark Benvenuto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||
| Sprint: | Platforms 2017-09-11, Platforms 2017-10-02, Platforms 2017-11-13, Platforms 2018-01-01, Platforms 2018-01-15 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
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
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 |
| Comments |
| Comment by Githook User [ 01/Mar/18 ] |
|
Author: {'email': 'mark.benvenuto@mongodb.com', 'name': 'Mark Benvenuto', 'username': 'markbenvenuto'}Message: (cherry picked from commit 4bc1ea069e0f9ad04af93a1442d31b87b34ddd25) |
| Comment by Githook User [ 04/Jan/18 ] |
|
Author: {'name': 'Mark Benvenuto', 'username': 'markbenvenuto', 'email': 'mark.benvenuto@mongodb.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 23/Sep/17 ] |
|
Bruce - OK, I don't mind re-opening it as we continue to investigate. I will assign it to Mark. I suspect though that if we find that we still do want to do this with the adaptive executor, that we will want a distinctly different strategy for calling MarkThreadIdle. |
| Comment by Henrik Edin [ 22/Sep/17 ] |
|
Most of the problems should have gone away with the resolution of |