UMS Slow and consuming lots of CPU and RAM
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
UMS Slow and consuming lots of CPU and RAM
Hi guys,
after my first try to use UMS 9 years ago I see it is developing well.
So I thought I give it a try again. I am normally using Serviio since many years.
I install the UMS AppImage 14.13.1 on an Ubuntu 24.04 LTS LXC container in Proxmox.
Installing, starting and configuring UMS is perfectly fine, but I realized browsing a folder with ~100 albums (so not really a long list) with my Yamaha AV Reciever App is causing the 2 CPUs in the LXC container to run at max load and 1,3GB of RAM is used.
Scrolling through the list of these ~100 music albums while the albums cover are loaded and display in the list is slow and sometime it takes several seconds until all albums covers are visible.
If I start to stress UMS a bit with scrolling up and down and up and down in the list of albums, the UMS gets inaccessible by the Yamaha DLNA APP and stays on a high CPU and RAM load. It stays unusable until i restart UMS.
In the debug log (see attachement) I found several java.lang.OutOfMemoryError. I wonder if UMS really needs so much RAM.
Compared with Serviio (running as well in its own Ubuntu LXC container with the same number of CPUs and amount of RAM), which is consuming very few CPU power and RAM, the albums covers from the same list of albums appear immediately and it is not crashing even if I stress it.
Any idea?
Thanks in advance for any help.
after my first try to use UMS 9 years ago I see it is developing well.
So I thought I give it a try again. I am normally using Serviio since many years.
I install the UMS AppImage 14.13.1 on an Ubuntu 24.04 LTS LXC container in Proxmox.
Installing, starting and configuring UMS is perfectly fine, but I realized browsing a folder with ~100 albums (so not really a long list) with my Yamaha AV Reciever App is causing the 2 CPUs in the LXC container to run at max load and 1,3GB of RAM is used.
Scrolling through the list of these ~100 music albums while the albums cover are loaded and display in the list is slow and sometime it takes several seconds until all albums covers are visible.
If I start to stress UMS a bit with scrolling up and down and up and down in the list of albums, the UMS gets inaccessible by the Yamaha DLNA APP and stays on a high CPU and RAM load. It stays unusable until i restart UMS.
In the debug log (see attachement) I found several java.lang.OutOfMemoryError. I wonder if UMS really needs so much RAM.
Compared with Serviio (running as well in its own Ubuntu LXC container with the same number of CPUs and amount of RAM), which is consuming very few CPU power and RAM, the albums covers from the same list of albums appear immediately and it is not crashing even if I stress it.
Any idea?
Thanks in advance for any help.
- Attachments
-
- ums_dbg_2025-08-24-15-57.zip
- (50.37 KiB) Downloaded 2677 times
Re: UMS Slow and consuming lots of CPU and RAM
I'm runnung UMS on a Linux server (Gentoo Linux)
I was getting the "OutOfMemory" issue with UMS V14.12 and it is also present in V14.13
I reverted back to UMS V14.11 and the "OutOfMemory" issue does not happen.
The problem has been reported and hopefully it can be resolved soon.
In the meantime, you could try UMS V14.11 and see if that runs without the "OutOfMemory" issue.
I was getting the "OutOfMemory" issue with UMS V14.12 and it is also present in V14.13
I reverted back to UMS V14.11 and the "OutOfMemory" issue does not happen.
The problem has been reported and hopefully it can be resolved soon.
In the meantime, you could try UMS V14.11 and see if that runs without the "OutOfMemory" issue.
Re: UMS Slow and consuming lots of CPU and RAM
I can see they are coming from the thumbnails but those logs were not in trace mode for some reason so I can't tell exactly what is causing it to run out of memory.
I don't know if it is when generating them or retrieving them from the database.
Try making some new logs following the section in red above to make sure they are in trace mode and it may reveal the cause.
I think for some people UMS is not shutting down fast enough to switch log modes, It took a few min for mine the other day for some reason when I was updating.
It may be something to do with your configuration of the container but I know nothing about this and very little about Linux so can't be much help.
I know there is a docker version but had never heard of LXC.
As boss says try v14.11 and see if that has the same problem. I don't think this is the same issue as he had in v14.12 though but this can help rule this out.
Code: Select all
WARN 2025-08-24 15:55:57.979 [jupnp-stream-server-72] /ums/thumbnail/9ab0c000-f668-11de-9976-ccd42ebd129a/10244/JPEG_SM_Whitney-Houston-The-Best-of.jpg
java.lang.OutOfMemoryError: Java heap space
at java.desktop/java.awt.image.DataBufferByte.<init>(Unknown Source)
at java.desktop/java.awt.image.ComponentSampleModel.createDataBuffer(Unknown Source)
at java.desktop/java.awt.image.Raster.createWritableRaster(Unknown Source)
at java.desktop/javax.imageio.ImageTypeSpecifier.createBufferedImage(Unknown Source)
at java.desktop/javax.imageio.ImageReader.getDestination(Unknown Source)
at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)
at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)
at com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:355)
at net.pms.image.ImageIOTools.read(ImageIOTools.java:121)
at net.pms.image.ImageIOTools.read(ImageIOTools.java:70)
at net.pms.image.ImagesUtil.transcodeImage(ImagesUtil.java:1090)
at net.pms.image.ImagesUtil.transcodeImage(ImagesUtil.java:946)
at net.pms.image.ImagesUtil.transcodeImage(ImagesUtil.java:618)
at net.pms.dlna.DLNAThumbnailInputStream.transcode(DLNAThumbnailInputStream.java:211)
at net.pms.network.mediaserver.servlets.MediaServerServlet.sendThumbnailResponse(MediaServerServlet.java:748)
at net.pms.network.mediaserver.servlets.MediaServerServlet.doGetHead(MediaServerServlet.java:168)
at net.pms.network.mediaserver.servlets.MediaServerServlet.doGet(MediaServerServlet.java:89)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
at net.pms.network.mediaserver.servlets.MediaServerHttpServlet.service(MediaServerHttpServlet.java:35)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736)
at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1622)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:823)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:440)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1071)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:151)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:678)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
Try making some new logs following the section in red above to make sure they are in trace mode and it may reveal the cause.
I think for some people UMS is not shutting down fast enough to switch log modes, It took a few min for mine the other day for some reason when I was updating.
It may be something to do with your configuration of the container but I know nothing about this and very little about Linux so can't be much help.
I know there is a docker version but had never heard of LXC.
As boss says try v14.11 and see if that has the same problem. I don't think this is the same issue as he had in v14.12 though but this can help rule this out.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: UMS Slow and consuming lots of CPU and RAM
Reverting to 14.11 does not help.
Lots of errors in the log and the UMS is crashing.
To start UMS in tracelog mode seems not to work as well.
I don't want to be impolite, but coming back to UMS after about 10 years and seeing that it is crashing, it consumes lots of CPU power and memory, throwing many errors in more or less normal usage... is really disappointing.
You have over 100 contributors on github, while Serviio is mainly done by Petr Nejedly alone, as far as I know.
This leaves me with the impression that too many guys are coding without a minimum of software testing and code quality checks.
I will stays with Serviio.
Lots of errors in the log and the UMS is crashing.
To start UMS in tracelog mode seems not to work as well.
I don't want to be impolite, but coming back to UMS after about 10 years and seeing that it is crashing, it consumes lots of CPU power and memory, throwing many errors in more or less normal usage... is really disappointing.
You have over 100 contributors on github, while Serviio is mainly done by Petr Nejedly alone, as far as I know.
This leaves me with the impression that too many guys are coding without a minimum of software testing and code quality checks.
I will stays with Serviio.
- Attachments
-
debug.log- (1.12 MiB) Downloaded 2872 times
Re: UMS Slow and consuming lots of CPU and RAM
It's still not in trace mode. Try following the instructions in the red section above.
If that does not work then add this to /home/ums/.config/UMS/UMS.conf to force it when it starts
The logs from 14.11 do show errors that are not in the other one.
These have to do with unable to get metadata from Musicbrainz but will need to see trace logs for what is causing the error.
There could also be a conflict to the database versions so try doing a clean install.
If that does not work then add this to /home/ums/.config/UMS/UMS.conf to force it when it starts
Code: Select all
log_level =traceThese have to do with unable to get metadata from Musicbrainz but will need to see trace logs for what is causing the error.
Code: Select all
ERROR 2025-08-30 16:13:49.253 [jupnp-stream-server-1258] Could not lookup audio data for "Gulity": musicbrainz.org replied with status code 503
WARN 2025-08-30 16:13:49.255 [jupnp-stream-server-1258] /ums/thumbnail/9ab0c000-f668-11de-9976-ccd42ebd129a/9999/JPEG_SM_Barbra+Streisand+-+Guilty+%28Official+Audio%29+ft.+Barry+Gibb.mp3.jpg
java.lang.InternalError: java.lang.reflect.InvocationTargetException
at java.desktop/sun.font.FontManagerFactory$1.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at java.desktop/sun.font.FontManagerFactory.getInstance(Unknown Source)
at java.desktop/sun.font.SunFontManager.getInstance(Unknown Source)
at java.desktop/sun.font.FontDesignMetrics.getMetrics(Unknown Source)
at java.desktop/sun.java2d.SunGraphics2D.getFontMetrics(Unknown Source)
at net.pms.util.GenericIcons.createGenericIcon(GenericIcons.java:284)
at net.pms.util.GenericIcons.getGenericIcon(GenericIcons.java:191)
at net.pms.store.StoreResource.getGenericThumbnailInputStreamInternal(StoreResource.java:513)
at net.pms.store.StoreItem.getGenericThumbnailInputStreamInternal(StoreItem.java:1411)
at net.pms.store.StoreResource.getGenericThumbnailInputStream(StoreResource.java:531)
at net.pms.store.StoreResource.getThumbnailInputStream(StoreResource.java:565)
at net.pms.store.item.RealFile.getThumbnailInputStream(RealFile.java:303)
at net.pms.store.StoreResource.fetchThumbnailInputStream(StoreResource.java:552)
at net.pms.network.mediaserver.servlets.MediaServerServlet.sendThumbnailResponse(MediaServerServlet.java:739)
at net.pms.network.mediaserver.servlets.MediaServerServlet.doGetHead(MediaServerServlet.java:167)
at net.pms.network.mediaserver.servlets.MediaServerServlet.doGet(MediaServerServlet.java:88)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
at net.pms.network.mediaserver.servlets.MediaServerHttpServlet.service(MediaServerHttpServlet.java:35)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736)
at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1619)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1552)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:819)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:436)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1060)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:151)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:662)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:418)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException: null
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source)
at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
... 38 common frames omitted
Caused by: java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration
at java.desktop/sun.awt.FontConfiguration.getVersion(Unknown Source)
at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(Unknown Source)
at java.desktop/sun.awt.FontConfiguration.init(Unknown Source)
at java.desktop/sun.awt.X11FontManager.createFontConfiguration(Unknown Source)
at java.desktop/sun.font.SunFontManager$2.run(Unknown Source)
at java.desktop/sun.font.SunFontManager$2.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at java.desktop/sun.font.SunFontManager.<init>(Unknown Source)
at java.desktop/sun.awt.FcFontManager.<init>(Unknown Source)
at java.desktop/sun.awt.X11FontManager.<init>(Unknown Source)
... 43 common frames omittedLogs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: UMS Slow and consuming lots of CPU and RAM
I came here to post a fixed version for the user to test but they said they will stick with Serviio, ah well 
thanks for trying to help them mik_s!
thanks for trying to help them mik_s!