Memory leak, just sharing some preliminary info #2348
Replies: 21 comments 58 replies
-
Thanks for the update. Last we checked, more of the memory usage troubles are linked with the OCaml memory manager. Not necessarily memory leaks in the C sense, i.e. lost allocated memory pointers, but, rather, the memory manager keeping too much memory alive, for good or bad reasons. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Ok, here's some more graphs. I think 2 more days will be enough to see final trends. Hypotheses
|
Beta Was this translation helpful? Give feedback.
-
Thanks for these reports. I'm gonna have another pass at it. Before I do, tho, just wanted to confirm: What version of |
Beta Was this translation helpful? Give feedback.
-
Hypothesis 1 |
Beta Was this translation helpful? Give feedback.
-
@vitoyucepi I've rebuilt most of the binary builds for the rolling releases using OCaml All the |
Beta Was this translation helpful? Give feedback.
-
Actually, would you mind checking with the builds from this run: https://github.com/savonet/liquidsoap/actions/runs/2463570986 |
Beta Was this translation helpful? Give feedback.
-
The results with a0d67fa |
Beta Was this translation helpful? Give feedback.
-
I've been running the test script on a ubuntu focal with the build here: https://github.com/savonet/liquidsoap/actions/runs/2484217096 ( |
Beta Was this translation helpful? Give feedback.
-
I got tired of the jingles, renamed the repository so the playlist resolution would fail and it started leaking. I'm not sure if that's the cause of your leak but this one was traced down to a missing |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Hi, I'm seeing multiple customers having memory leaks with version 2.0.4, 2.0.5 and 2.0.6. The issue i'm describing does not occur with 2.0.3. I see most processes running with 150MB RSS memory. Within approximately 1 hour we see some creep up over 2 GB memory; even up to 5 GB in some instances. Its causing the system OOM to kill database servers and other processes trying to conserve memory. I have tested with Liquidsoap 2.0.3, 2.0.4, 2.0.5 and 2.0.6 with OCAML 4.14.0. Interestingly of the ~15 liquidsoap processes running on this server i'm actively watching the memory usage growing on some where others don't budge. I've enabled logging and I can see the below request constantly every few seconds which might be relevant. It's generating a 500 error from liquidsoaps harbor endpoint, which i assume is coming from the clients encoder in shoutcast mode with something like sam broadcaster that checks listener stats (passwords and ips removed). In version 2.0.3, the same 500 error is returned but the memory isn't increasing. Liquidsoap 500 Error
This particular system is CentOS 7.9 with samplerate pinned to 0.5.0 (newer versions wont compile with CentOS 7.9) opam list
liquidsoap script
|
Beta Was this translation helpful? Give feedback.
-
Thanks for the update @TheRealMattLear. This may or may not be related to @vitoyucepi's own issue but does look a lot like the issues reported in #1122 We're actively testing this and fixing and we find issues. Let's keep using this conversation to report issues and ways to potentially reproduce them. I'll check on your script very shortly. |
Beta Was this translation helpful? Give feedback.
-
Sounds good @TheRealMattLear . I'm glad y'all have a work around. I looked at the code diff and there isn't much indicative of changes that would create this kind of behavior so I'm leaning toward a bug that was already there but appears with some level of randomness. On my local experiment, it seems that I might have hit the situation. This is with @vitoyucepi's script, I'm letting it run a little more to see how it evolves. |
Beta Was this translation helpful? Give feedback.
-
Quick update on this issue:
Running the script again, I now get this memory profile: I think the next steps for me are:
And hope we get more clarity. The latest rolling release builds should all have the two ogg and opus fixes above now. |
Beta Was this translation helpful? Give feedback.
-
Ok, we found another issue related to over-allocating around It looks to me that I cannot reproduce the issue anymore. |
Beta Was this translation helpful? Give feedback.
-
It looks like everything is fixed for me here: It'd be nice if you could send even an early report. Otherwise, I'm contemplating doing a |
Beta Was this translation helpful? Give feedback.
-
Thanks for sharing that. Is it still growing? |
Beta Was this translation helpful? Give feedback.
-
Thanks for sharing that. There's definitely some improvements with the opus leak fix. The plan as I see it is:
|
Beta Was this translation helpful? Give feedback.
-
This is the 21 hours of running
2.0.4
, and it seems that memory leaks. I will monitor some more before finally will create a new issue. I assume that it exists before2.0.4
release.Graph legend:
elapsed_time
, seconds since start.resident_memory[i]/total_memory
,total_memory
is 2GB;cpu_time[i]/elapsed_time[i]
for cumulative;savgol_filter((cpu_time[i] - cpu_time[i-1]) / (elapsed_time[i] - elapsed_time[i-1]), 50, 3)
;uniform_filter1d((cpu_time[i] - cpu_time[i-1]) / (elapsed_time[i] - elapsed_time[i-1]), size = 100)
.Beta Was this translation helpful? Give feedback.
All reactions