Server Version#: 1.43.5.11079
Player Version#: N/A
I’ve had Plex running on various versions of OMV for some time. It’s currently running under OMV v8, which sits on top of Debian 13 (trixie). Starting from a couple of Plex upgrades ago, the server goes from 4% memory use to 90+% memory use overnight, consistently. I’ve disabled DLNA and unchecked all of the scheduled tasks and the memory still gets consumed overnight.
Rebooting the server and stopping PMS results in no such memory consumption.
Downgrading to 1.42.2 or possibly 1.41.2.2 (sorry, can’t remember the exact version now) also doesn’t result in massive memory consumption.
I found and ran DBRepair and said everything was fine, so I’m all out of ideas. Does anyone have any suggestions as to where I could start looking next?
I have Analyze audio tracks for loudness set as “as a scheduled task”, but there’s no separate settings which seem to govern it under Scheduled Tasks (all of which are unticked now, to see if any of them were causing the problem).
I don’t think you can easily disable it.
The activities which can be configured in the scheduled tasks are recurring jobs while the loudness analysis is a one off activity (similar to basic analysis, intro/credits detection etc.
You can modify the library maintenance window or check the activity pane in Plex Web during maintenance to see if your server is performing the loudness analysis.
That seems a bit opaque. Anyway, ran some tests, disabled loudness analysis and all the other scheduled tasks and it seems to have only “eaten” about 10% memory overnight, which is a massive improvement. I wonder if any of the other items under Library which are set to run “as a scheduled task” are leaking smaller amounts too. I’ll do some tests. Thanks for the pointer.
I’m not sure I understand what you mean. It seems that memory usage is considerably less when I elect to never analyse loudness, irrespective of whether it’s using cache for that process or not.
I understand the terminology, and that not releasing memory is a leak. I don’t understand what the relevance is of “it’s possible it’s using cache which [is] typical usage and not a memory leak”.
Memory usage jumps from 4% to 90% overnight when Plex is running, it doesn’t jump when Plex isn’t running, and jumps considerably less when audio loudness analysis is turned off. So the reference to cache seems irrelevant (unless I’ve misunderstood what was meant) since it appears to be not releasing memory (i.e., a leak).
Memory is cache. If a process or OS is offloading data to ram in a cache, then ram usage will climb. When you were running analysis, you complained ram usage was high. But you did not say if it was paged memory or cache memory. Many OS will aggressively use cache memory and it will release that to be used as needed. As the old adage says, free memory is wasted memory.
Thanks for the reply. I understand that memory is cache, but why wouldn’t all memory (paged and cached) used by the process not be released when the scheduled tasks end (6am, for me)? Does the kernel clear unused pages periodically, or does the application have to notify the kernel that it no longer requires the memory it requested?
I’ve reset loudness analysis back to being a scheduled job and will check detailed memory stats in the morning (OMV’s dashboard widget just gives overall free/used figures).
mem shows 28gb of 30gb used and 2gb available. /proc/meminfo shows 1gb cached and 4kb dirty. Same thing again overnight - memory goes from 4% in use overall to 94%. I’m presuming that since “Analyze audio tracks for loudness” is set to “as a scheduled task”, and scheduled tasks are set to run from 0200 to 0600, by 0900 the analysis has stopped and the memory should be release.
Questions, just out of curiosity. How did you discover this “leak?” Are there adverse performance issues? Are other processes failing to start, or dying because of it?
OMV emailed a warning that: mem usage of 90.7% matches resource limit [mem usage > 90.0%]. Usage is never that high, ordinarily. No, no other processes are failing to start, nor dying because of it, as far as I know. (That’s a fair question, because it might be one of those non-problem type problems!) The server is relatively lightly used, mainly as a file store, Plex server and DocFetcher server.
I would’ve thought the memory would’ve been released when the scheduled tasks finish but maybe my understanding of memory management is too rudimentary.
That’s possible. OS memory management can be a little unintuitive. It doesn’t necessarily just “release” everything as activities stop. Things can be marked as cached, but available. So if something else comes along that needs memory, it’s allocated from that memory.
It was stated above, but the general idea is that free memory is wasted memory. It would be more useful to see if other apps fail because of this.
I don’t mean to suggest your observations don’t mean anything. But when certain problems exist, there will be consequences. You’ll start seeing the out of memory (OOM) killer trigger. Or other failures.
Having said that, do you have loudness analysis enabled for your libraries? Now?
Yeah, I started reading up a bit more about it (OS memory management) and it’s a rabbit hole! I knew some memory was released ah-hoc but I thought big chunks like this were released when the associated process terminated. I’ll not bounce the server, and see if any problems ensue. Libraries are set for loudness analysis for now. I’ll monitor.
(Something is definitely different though, because 2 or 3 versions ago this wasn’t happening, and turning off the analysis dramatically improves the amount of reported free memory once the scheduled tasks have finished. I’ve not suddenly uploaded a load of media or changed the config in any way.)
Loudness analysis wasn’t a thing a few versions ago, except for music libraries. Now it’s on by default for all libraries to facilitate loudness normalization. It wasn’t very optimized in its first releases. I’d recommend keeping it enabled globally and then turning it off for everything except your music library. Or libraries. They’re optimizing it as has been shown in some forum previews.
Yes, that’s why I chose my words carefully! Too easy to say “something’s definitely wrong” when actually it may be just different, and as you say, different doesn’t necessarily mean bad.
