I have a memory leak

[baslking]

As of 9.0 May 25 commit, I have a memory leak. This is new, never seen it before. I pick up about 100KB on every new song being streamed from Tidal, haven't tried on local files, will do that tomorrow.

I'm using a bit of an esoteric version on Arch Linux, but I've been running for months on it. This is perl 5, version 38, subversion 2 (v5.38.2) built for aarch64-linux-thread-multi Operating System: Arch Linux ARM
Kernel: Linux 6.6.31-2-rpi Architecture: arm64

Lyrion Music Server Version: 9.0.0 - git-efa83999f @ 2024-05-25 11:13:29 +0200 Hostname:xxxx Server IP Address:xxx.xxx.xxxx.xxxx Server HTTP Port Number: 9000 Operating system: Linux - EN - utf8 Platform Architecture: aarch64-linux Database Version: SQLite Total Players Recognized: 2

Perl and Module Versions Perl Version: 5.38.2 - aarch64-linux-thread-multi Audio::Scan: 1.09 DBD::SQLite: 1.58 (sqlite 3.22.0) IO::Socket::SSL: 2.085 Mozilla::CA: Net::SSLeay: 1.94 - OpenSSL 3.3.0 9 Apr 2024

The slimserver-vendor package hasn't been updated for the last few weeks. I recognise that this is probably not enough info, but maybe someone else is seeing this?

[baslking]

seems to be leaking roughly 1M/song played either streamed from service or local files.

[michaelherger]

It's growing with every song, or does it settle after a while? How much is it using overall? What plugins are you using?

[baslking]

The main plugin that I'm really using is Tidal I have quite a few others turned on (search and tagging etc) I just launched off about 2500 local songs and I'll keep an eye on it. it's running around 180M as a starting point. It seemed to keep growing streaming tidal for about 100 songs, but I didn't push too far before restarting. I'll give it a day or 2

[baslking]

Just ran for 301 local songs. I started at 185MB and now it's at 234MB growing fairly steadily at about 160MB/song. I recompiled the CPAN modules before starting just in case (my distribution only has Perl 5.38 so there isn't an off the shelf build) I will continue to watch it, but after about 24hours I don't think it will level off. If nobody else is seeing this its probably something with my CPAN build. The players don't need any decoding so none of the helper binaries are running.

[michaelherger]

Can you check your numbers? 160MB/song times 301 song would result in... 48GB. I guess this should be 160kB?

A certain growth after restart can be considered normal. Caches are filling up here and there, the database is filling its buffers etc. But it should certainly level off at some point.

FWIW: my main LMS is currently at 229MB. But I admittedly restart quite often (every other day), as I'm trying to always run the latest and greatest.

[baslking]

Sorry, that is indeed 160kb/song. I,like you, have been updating and restarting every day or so with your frequent updates 👍 . I'll keep running for another couple days and see. My process has gone from 185MB to 248MB. 63MB seems like a lot, but maybe not.

[michaelherger]

As long as it doesn't further grow that's fine.

[baslking]

I'm at 306MB at 800 songs played still growing at 150KB/song after about 60hours

[michaelherger]

Yeah, something's not quite right, I'd say. Are you using any 3rd party plugins? What is your memory setting in Settings/Advanced/Performance?

[baslking]

Just upgraded and restarted at 1001 songs, seems to be slowing but still growing: went from 185M to 326MB still growing over 100KB/song after 3 days. It's a 1GB RPI. I had run for months back in the days of LMS when I used a binary distribution and upgrades were infrequent. Best i can tell no 3rd party plugins. Here's the perf settings, pretty plain vanilla:

[michaelherger]

Something's wrong there. What startup parameters are you using? I just bumped into an issue with my dev system where after about a day it had consumed >16GB! But that most likely was due to my using the --checkstrings parameter, which monitors changes to the strings file in an inefficient way.

[baslking]

/home/slimserver/git/slimserver/slimserver.pl \ --prefsdir /home/slimserver/prefs \ --cachedir /home/slimserver/cache \ --logdir /var/log/slimserver with the packaged perl: perl --version

This is perl 5, version 38, subversion 2 (v5.38.2) built for aarch64-linux-thread-multi

[baslking]

I think I've found something. After the 8 June upgrade with the reworking of the sql database I restarted and ran 150 songs with no memory leak, but I had been doing testing with 2 players running synchronized, and I switched to 1 player. To check if it's the updates or the 2 player sync I'm now running 2 players synchronized, if there's a leak would appear to be related to that. I can imagine that some sort of buffering might be needed to synchronize 2 players,? If not then it was fixed by some of the updates. Now running: Lyrion Music Server Version: 9.0.0 - git-bad40f25b @ 2024-06-09 07:58:30 +0200 I'll see where its at in a few hours.

[baslking]

So i can confirm memory grows about 150KB/song with 2 players in sync and it appears stable with a single player.

[michaelherger]

Are you using sync ad-hoc, or do you use the Group Player plugin?

[baslking]

I wasn't aware of the group player plugin, so I suppose ad-hoc, I've used it for years. I'll try the plugin...

[michaelherger]

I'm sure you mentioned what players you're using. Would you know whether transcoding is involved? Eg. would one of the players require the audio data to be transcoded form some format to something else?

[baslking]

So group and ad-hoc give similar results about 150K/song. I saw 66MB after 420 songs played I'm using squeezelite players that should not need any transcoding. My original hw is long dead. I also seem to see similar results for local and streaming content. I don't want to waste your time. It's easy enough to restart, especially If I am the only one with an issue

[baslking]

Update here, after updating to Perl 5.40, I'm seeing 13.5KB/song which grows much more slowly. So things are getting better.

Lyrion Music Server Status
Lyrion Music Server Version: 9.0.0 - git-f6ef66f16 @ 2024-09-09 09:43:19 +0200
Hostname: majordomo
Server IP Address: 172.16.16.13
Server HTTP Port Number: 9000
Operating system: Linux - EN - utf8
Platform Architecture: aarch64-linux
Database Version: SQLite
Total Players Recognized: 3

Perl and Module Versions
Perl Version: 5.40.0 - aarch64-linux-thread-multi
Audio::Scan: 1.09
DBD::SQLite: 1.58 (sqlite 3.22.0)
IO::Socket::SSL: 2.089
Mozilla::CA: Unknown
Net::SSLeay: 1.94 - OpenSSL 3.3.2 3 Sep 2024