Oneric
13e2a811ec
We’ve received reports of some specific instances slowly accumulating more and more binary data over time up to OOMs and globally setting ERL_FULLSWEEP_AFTER=0 has proven to be an effective countermeasure. However, this incurs increased cpu perf costs everywhere and is thus not suitable to apply out of the box. Apparently long-lived Phoenix websocket processes are known to often cause exactly this by getting into a state unfavourable for the garbage collector. Therefore it seems likely affected instances are using timeline streaming and do so in just the right way to trigger this. We can tune the garbage collector just for websocket processes and use a more lenient value of 20 to keep the added perf cost in check. Testing on one affected instance appears to confirm this theory Ref.: https://www.erlang.org/doc/man/erlang#ghlink-process_flag-2-idp226 https://blog.guzman.codes/using-phoenix-channels-high-memory-usage-save-money-with-erlfullsweepafter https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4060 Tested-by: bjo |
||
|---|---|---|
| .. | ||
| controllers | ||
| views | ||
| mastodon_api.ex | ||
| websocket_handler.ex | ||