Fix CLS hooked memory leak #5801
Merged
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
…emory leak (no async hooks disable call) fixed as well as changing how we use the CLS namespaces to allow us to destroy the namespace we use per request.
Rory-Powell
reviewed
May 11, 2022
Rory-Powell
approved these changes
May 11, 2022
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.
Description
After fixing the memory leak we found in our PouchDB usage we were still experiencing a slow leak, I found issues:
These two issues demonstrate a memory leak that is related to the async hooks not being cleared up when the context is finished. We also had an issue with using a single static and global namespace which could not be destroyed. First I changed how our context functions work, so that there are two contexts, a single global one which stores the ID of a namespace which is created per request, then the request namespace which is created and destroyed as part of the run. I tested this by taking periodic snapshots of the heap state and comparing them while the app service was under heavy load, before these changes I would see a few structures grow in count in a linear fashion compared to the number of requests, e.g. PouchDB objects left over after being closed.
Once these changes were implemented all of these structures were no longer present, the memory usage would remain constant across all of the snapshots.