-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix memory leak and inconsistent behavior in memory caches #14314
fix memory leak and inconsistent behavior in memory caches #14314
Conversation
このPRによるapi.jsonの差分 差分はこちら |
0a00342
to
2d9d548
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #14314 +/- ##
============================================
- Coverage 40.07% 20.49% -19.59%
============================================
Files 1524 702 -822
Lines 188792 98756 -90036
Branches 3515 1027 -2488
============================================
- Hits 75666 20243 -55423
+ Misses 112552 77992 -34560
+ Partials 574 521 -53 ☔ View full report in Codecov by Sentry. |
Thanks for the PR! Since it seems redundant to make everything configurable about the cache used inside the system, and since this is likely to change as development progresses, it would be better to make it possible to set some single factor that applies to the entire system, such as the “rate limit” setting in the role policy. (This is my opinion and I am looking for your feedback) |
This has been replaced by #14363 |
What
This PR resolves #14310 and #14311 by refactoring
MemoryKVCache<T>
. The new implementation supports capacity limits with Least Recently Used (LRU) eviction, and no longer requires garbage collection or manual disposal. All references to this class have been updated to specify a reasonable capacity limit.Additionally, all cache lifetimes and capacity limits have been exposed as configuration values. This allows the limits to be adjusted by instance admins to account for available system resources, which reduces the chance of cache-related resource exhaustion. Larger instances can even increase the limits, thus improving cache hit rate and reducing churn.
Why
The linked issues pose a serious reliability issue that is affecting many instances, including my own. Resolving the memory leaks will improve stability, uptime, and performance.
Additional info (optional)
This change is upstreamed from the Sharkey fork. Please see Sharkey MR #580 for additional details and context.
Checklist