Possible Memory Leak - Out of memory 98% processor

[Sami32]

@uxb Some renderers, like LG, have a limitation of 1000 files by folder, so if it's the case of your, the test should be fast and straith...

[uxb]

@uxb Some renderers, like LG, have a limitation of 1000 files by folder, so if it's the case of your, the test should be fast and straith...

This does not appear to be the case in this instance. I added the directive LimitFolders=1000 into the {render}.conf file that the TV uses and added the share back into the UMS navigation pane. Within a few hours the memory useage started to climb and after a day of use UMS used up all the Java memory and went into the 90% CPU usage mode. I had to kill the Java process since UMS was no longer responding.

Like I said the folder in question (\Music) consists of 1500 folders that in total contain over 22,000 files. The other two folders I have are \TV that consists of 190 folders (give or take) and around 1800 files (it varies) and \Movies that consists of 344 folders and 533 files. Once I remove the \Music folder from the share the java memory never gets above the 250 tick mark on the UMS front panel and runs perfectly.

I suspect that it is either the way UMS handles the volume of files as it builds it's index or else one of more of the files in that folder is causing the issue in some way. Since I don't have particular knowledge for parsing the trace logs so I cannot tell which. I will leave the logs available for download in messages above in case you want to look at them.

Thank you.

[Sami32]

So you can try changing your memory heap size as already told, or test if one particular subfolder inside your Music repertory give this issue and submit a new log with only this problematic folder in the shared tab, as your actually log files are huge !!!

[uxb]

as your actually log files are huge !!!

It takes over a day for the crash to occur as the memory is consumed. When I have time I will try increasing the heap and/or removing files from that folder. From your cursory look at the logs is there anything in them that seems out of normal?

The reason I ask is that in the beginning of the logs I see a large number of trace lines like this:

TRACE 2017-01-07 14:22:44.984 [New I/O worker #4] net.pms.network.RequestHandlerV2 Ignoring self-originating request

Then later in the logs I see a number of trace entries that say:

TRACE 2017-01-08 13:53:19.637 [New I/O worker #1] net.pms.configuration.FormatConfiguration Format "mp3" failed to match supported line

Not knowing what they actually mean I don't Know if they are relevant.

[Nadahar]

Neither of those messages indicate anything wrong or are at all "noteworthy". The first is actually a bit complicated to explain, but it's something that UMS just does from time to time. The second is generated when you try to play a file and and UMS is trying to figure out how to deliver (stream/transcode) a certain content and checks all the "supported" lines in the renderer configuration.

[Sami32]

@uxb You could also try to add

Code: Select all

atz_limit = 25000

in your renderer configuration file, to verify that's not linked to the creation of virtual subfolders while outpassing 10000 files in folders.