OpenJDK has extreme CPU usage

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Post Reply
fivefivefiver
Posts: 1
Joined: Wed Sep 15, 2021 11:16 pm

OpenJDK has extreme CPU usage

Post by fivefivefiver »

Whenever I start UMS the OpenJDK Platform Binary process immediately goes to at least 55% CPU usage and stays there. This happens even without playing any content.
Taskmgr_2021-09-15_13-29-47.png
Taskmgr_2021-09-15_13-29-47.png (16.73 KiB) Viewed 3886 times
Once the problem started, I did a full uninstall, which didn't help. I even rolled back to an older version (9.8.3), but that didn't help matters either.

Ever since this issue appeared, I found that transcoding and playback were extremely choppy - to the point of being unwatchable.

Any idea what causes this issue?

I attached relevant logs below.
Attachments
ums_dbg_2021-09-15-13-26.zip
(677.76 KiB) Downloaded 150 times
User avatar
mik_s
Moderator
Posts: 1114
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: OpenJDK has extreme CPU usage

Post by mik_s »

Not sure what is happening here. I think something is wrong with your network configuration but I know little about it.
I see a lot of activity to 2 IPs.
192.168.1.1 is being marked as unrecognised but no other info about it. I'm guessing that is your router and UMS is not logging anything else, but if that was the case it wouldn't even mention it in the logs in the first place.
192.168.1.102 is the other renderer being marked as unrecognised but I'm pretty sure that is the IP of your computer which I don't understand. Usually this is from Windows Media Player and UMS will detect that but that is not the case here.
every time UMS sees that IP it creates a new thread which is probably causing the increased CPU usage

Code: Select all

[HTTPv1 Request Worker 9618] Matched media renderer "Unknown renderer" based on address 192.168.1.102
something that might be relevant

Code: Select all

Received a M-SEARCH from [192.168.1.102:51467]: M-SEARCH * HTTP/1.1
ST: urn:schemas-upnp-org:device:MediaRenderer:1
HOST: 239.255.255.250:1900
MX: 3
MAN: "ssdp:discover"

I would expect the HOST to be the same IP as the computer but this is 239.255.255.250, I can't see where that IP is coming from.

I see that you have a VPN, maybe that is causing the issue but UMS is not using that as a network interface so I'm not sure.
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.
User avatar
SubJunk
Lead Developer
Posts: 3705
Joined: Sun May 27, 2012 4:12 pm

Re: OpenJDK has extreme CPU usage

Post by SubJunk »

Yes like mik_s said there is something on that network really spamming. It looks like it is coming from Google Chrome. As you can see it is sending 1 request every millisecond (1000 per second) in some cases:

Code: Select all

TRACE 2021-09-15 13:25:06.684 [UPNPHelper] Received a M-SEARCH from [192.168.1.102:55193]: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/93.0.4577.63 Windows


TRACE 2021-09-15 13:25:06.685 [UPNPHelper] Received a M-SEARCH from [192.168.1.102:51467]: M-SEARCH * HTTP/1.1
ST: urn:schemas-upnp-org:device:Basic:1
HOST: 239.255.255.250:1900
MX: 3
MAN: "ssdp:discover"


TRACE 2021-09-15 13:25:06.686 [UPNPHelper] Received a M-SEARCH from [192.168.1.102:55193]: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/93.0.4577.63 Windows
Do you have any Chrome extensions installed that could account for this? Or maybe some browser service in a tab that does network things?
tanwedar
Posts: 4
Joined: Mon Sep 06, 2021 10:18 am

Re: OpenJDK has extreme CPU usage

Post by tanwedar »

I had a post earlier about this, though I was running Edge (both are chromium browsers). SSDP is related to UPnP and reaching out to the whole network from what I gather lazily reading up on the service. Create and run a .reg file with this content:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableMediaRouter"=dword:00000000
If you want to disable it in both browsers include:

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"EnableMediaRouter"=dword:00000000
If it gives you issues trying to add it you may need to run regedit as an admin then import the file. This is from the settings pages on either browser: "Have the Media Router connect to Cast devices on all IP addresses, not just RFC1918/RFC4193 private addresses. – Mac, Windows, Linux" -- So all IPs explains the spam the others talk about. I created these registry keys and restarted my browsers (gave it ~30 sec wait) and neither are giving the ssdp/multiscreen spam anymore. I tried changing the setting in chrome://flags and edge://flags, but it didn't work I had to use the registry entry. The flags didn't visually change from default to disabled, but it still effected the browser. Catch: you can't cast from your browser with the routing disabled. So - if you want to leave a browser open and not have the hiccup you can't cast. If you don't make the change and after closing your browser you still have the issue make sure you go to Chrome's settings and search for "Continue running background apps when Google Chrome is closed" and disable it (I recommend this anyway since Chrome eats resources). The last option you have as a workaround for this is to disable it in Chrome and use another browser (ie Edge) for your casting if you do cast from the same computer you run UMS on... or just cast from a different computer like a laptop I guess.

Please note I am not affiliated with UMS nor am I giving official support for Microsoft so any changes you make to your system are your own choice and I am not responsible for any frowning, frustration, keyboard smashing, or problems you may have as a result. If you are happy with results I will accept credit though ;)
Post Reply