[6.0] Modify thread pool thread counting to be a bit more defensive #70479
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Port of dotnet#70478 to 6.0 - An unexpected underflow in one or more thread counts can lead to a large number of threads to be created continually - Prevented underflows in changes to thread counts, such that following an unexpected underflow, subsequent paired increments and decrements would avoid repeating the underflow - Verified by creating an unexpected underflow in the debugger
|
Tagging subscribers to this area: @mangod9 Issue Details
|
janvorli
approved these changes
Jun 9, 2022
jeffschwMSFT
approved these changes
Jun 9, 2022
jeffschwMSFT
added
Servicing-approved
|
@kouvel/ @mangod9 thoughts on the failures? |
|
both are failing with Helix queue issues:
I will retry if this is somehow intermittent. |
|
This would need backport of #69871 looks like |
|
PR for the infra change is here: #70570. @jeffschwMSFT since this is only a infra change hoping doesnt need a full approval process. |
mangod9
approved these changes
Jun 10, 2022
|
/azp run runtime |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Customer Impact
It was seen a few times that when all worker threads have exited, somehow there is a decrement on the tracked thread counts, which leads to some counts going negative. As work is queued to the thread pool thereafter, this leads to additional threads being created and for the underflow to repeat when those threads run out of work. Combined with hill climbing frequently resetting the desired count of threads, the issue keeps repeating and more and more worker threads are created. The issue appears to be very rare, but when it occurs, it can lead to the process accumulating >> 100K threads over a relatively short span of time, and with a large amount of CPU time spent in spinning up and tearing down worker threads. This is a defensive fix to have the thread pool behave less erratically in the event of an unexpected underflow.
Regression?
The issue started happening in .NET 6 with the portable thread pool. The reason for the unexpected underflow being seen is not clear. There doesn't appear to be a realistic possibility of underflow in the source code or generated machine code. Whether it is a regression is unclear at the moment.
Testing
Verified the issue and fix by creating an unexpected underflow in the debugger and monitoring the process thread count following that.
Risk
Low - If there is no underflow, the behavior is the same as before.