This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Limit how often we do a GC. #9890
Comments
|
How does letting python trigger the GC automatically fare to this? Does python itself have a smart algorithm (or the sorts) that makes it able to "back off" in such a fashion? #9813 |
|
We use the exact same algorithm as python already, the only thing we do is ensure they happen after a reactor tick, but as per the issue that shouldn't make any difference. |
erikjohnston
added a commit
that referenced
this issue
Apr 28, 2021
Synapse can be quite memory intensive, and unless care is taken to tune the GC thresholds it can end up thrashing, causing noticable performance problems for large servers. We fix this by limiting how often we GC a given generation, regardless of current counts/thresholds. This does not help with the reverse problem where the thresholds are set too high, but that should only happen in situations where they've been manually configured. Adds a `gc_min_seconds_between` config option to override the defaults. Fixes #9890.
erikjohnston
added a commit
that referenced
this issue
May 5, 2021
Synapse can be quite memory intensive, and unless care is taken to tune the GC thresholds it can end up thrashing, causing noticable performance problems for large servers. We fix this by limiting how often we GC a given generation, regardless of current counts/thresholds. This does not help with the reverse problem where the thresholds are set too high, but that should only happen in situations where they've been manually configured. Adds a `gc_min_seconds_between` config option to override the defaults. Fixes #9890.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We support configuring the GC thresholds via the
gc_thresholdsconfig option, however the default can lead to a lot of GC churn on busier instances. This can easily lead to a) a CPU usage by GC of ~20% and b) multiple multi second GC pauses in quick succession.Since we manually run the GC we could add limits to ensure we don't run the GC e.g. gen 0 no more than once a second, gen 1 no more than once every 10s and gen 2 no more than once every 30s. This a) enforces that we don't repeatedly do gen2 really frequently and b) stops objects getting promoted to gen2 far too quickly.
The text was updated successfully, but these errors were encountered: