mvordeme wrote:
> Just for your encouragement, since you seem pretty well on your way
> without interference from my side: It seems that I can observe the leak
> as well with standard transcoding settings, only it is so subtle that I
> will probably upgrade my LMS before the Pi runs out of memory. My LMS is
> up since about 20 days, and it currently has the following memory
> footprint. So far, I have never seen it shrink.
> >
Code:
--------------------
> > Mem: 1808960K used, 145392K free, 94768K shrd, 21020K buff, 1121756K
cached
> CPU: 1.2% usr 0.0% sys 0.0% nic 98.6% idle 0.0% io 0.0% irq 0.0% sirq
> Load average: 0.01 0.07 0.08 1/141 1992
> PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
> 32307 1 tc S 526m 27.5 0 0.4 {slimserver.pl} /usr/bin/perl
/usr/local/slimserver/slimserver.pl --daemon --user tc --group staff
--------------------
> >
Thanks a lot for the encouragement.
It seems to be correlated proportionally to the type of transcoding you
want to do.
As an example:
With very small files and light transcoding (to MP3 for ex) It takes
hours to show a minimum RAM usage above the normal (where normal Is
~120-200MB)
With a more intensive transcoding, like an upsampling of a FLAC file, It
Is pretty noticeable in a few minutes that the RAM usage starts
growing.
I tried with an Extreme case like FLAC->RAW 32bit/384kHz->1 milion taps
FIR filter -> DSD128 and the RAM usage of the perl process starts to
grow like Crazy (1gb After 2 songs).
What Is curious is that also the CPU usage grows proportionally, and I
mean not the CPU usage of the external utilities used for transcoding
but of the slimserv.pl process; in the last case It was using 30% of one
core of a xeon e5-2697 V3, which Is A LOT.
I'd like to solve it because I'm pretty much the only unofficial
maintainer of the version for FreeBSD/FreeNAS/TrueNas, and for the
moment, I answered to those who contacted me about this bug to set up a
cronjob to restart LMS periodically so it doesn't eat all the RAM.... As
a temporary "fix"
With Debian 64bit this bug does not seem to happen at all.
I tried to proceed on the 'memory debug' route.
2 of those modules needed for the memory debug were not working,
(B::Size and B::LexInfo) they are not maintained (for something like 15
years). I managed to fix them, but still MemoryUsage.pm gives another
error, It tries to call the 'FILL' method in the B::PADNAME class in
B::C, which, in fact, does not seem to exist. (See here
https://perldoc.perl.org/B#B::PADNAME-Methods)
In the mean time I managed to update all the CPAN modules in
slimserver-vendor and correct the building script accordingly (some of
them were out of date by more than 10yrs), Tomorrow I'll make the pull
request.
@philippe_44 or @mherger at this point I'm pretty stucked. If One of you
Is willing to help and try to recreate the bug in a local VM I'll send
you instruction in PM (It pretty quick to recreate It). I usually Always
try to find the way out by myself, but my weak knowledge of perl is
limiting and I'm a bit lost After all these failed attempts.
https://audiodigitale.eu
------------------------------------------------------------------------
Simonef's Profile: http://forums.slimdevices.com/member.php?userid=67438
View this thread: http://forums.slimdevices.com/showthread.php?t=113321
_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
