Server Version#: 1.14.1.5488
Player Version#: 3.77.4
Plex is using 100% of one of my CPU cores. Movie thumbnail generation disabled.
EDIT: CPU usage is @ 100% with absolutely nothing in the library. (Fresh Install)
If I delete all of the libraries, cpu usage is still at 100%. If PMS is restarted after everything is deleted, CPU usage drops to 0. If the libraries are re-added, CPU usage is still 0 until PMS is restarted (which resumes @ 100% again).
No activity - not sure why it’s chewing up an entire core.
Hi @DaveOke, I (and a few others on Mac, NAS and Linux) have had problems with this build of PMS running at 100% CPU. It’s been seen to stop happening if you revert to the previous release (1.14.0.5470).
Plex don’t make the older versions available but you can find them with a bit of Googling. See if 5470 sorts it for you.
It worked! I had to restart the PMS service to bring the CPU back down, but it’s down and stayed down now. It’s a workaround, not a fix, but it’s a start.
Could I ask what made you try turning off UPnP? It seems an odd route to take.
Had the same issue on a Linux server within a Docker container. If I specified --net=host it caused 100% CPU usage on 2 cores. With regular networking it wasn’t a problem.
Thanks for the hint about UPnP. This was actually the root of the problem.
This bug is still active in 1.15.3.835, blocking my Plex server from using UPNP really isn’t a fix, is this even reported and actively being worked on?
Yeah, we’ve been working on this slowly but surely with the Plex Team. tl;dr it’s looking to me like a bug in the PMS code that deals with parsing SSDP messages for network discovery. There’s a lot of SSDP/UPnP stuff goes on in the background even with Remote Access manually configured.
I’m also seeing this problem on v1.14.1.5488-cc260c476 running in Docker with host network, and using an OpenWrt router running miniupnpd 2.1.20180706-1. As I’m not willing to disable UPnP on my router, I decided to find a workaround.
At first I tried to add a firewall rule on the Docker host to drop packets with destination port 1900. This didn’t help however. After some tcpdumping, I noticed that Plex contacts the UPnP daemon, and receives a reply on a port other than 1900, but with source port 1900, so I added a firewall rule to drop packets with source port 1900:
iptables -I INPUT -p udp --sport 1900 -j DROP
Then restarted the Docker container, and the problem hasn’t appeared since. Hope this helps someone until the problem is resolved in Plex or miniupnpd.
That will certainly do the trick, but be aware that you’re blocking all inbound SSDP to PMS with that rule.
PMS sniffs around the network for DVRs, clients and other servers and these will be blocked. That’s no problem if you’re not using that functionality, obviously.
You may find that you see weirdness with Remote Access, too, if you’re blocking SSDP, specifically from your router. Even if you’re not using UPnP to configure your router PMS still uses the IGD SSDP functionality to discover your external IP address and check for double NAT.
Fortunately I’m not using Remote Access at all, I’m using VPN instead to access Plex when I’m away. For the detection of other devices on the network, the rule could be limited to drop only packets coming from the router. Thanks for bringing that to my attention!
This is still happening with 1.16.0.1220 running in a Docker container with network host mode.
Changing to bridge mode stops the 100% CPU peg. It requires manual port forwarding which is a hassle, but better than never-ending max CPU load.
Thanks dersimn for the work-around.
To gary_parker and the Plex dev team: Why not rate limit the SSDP polling? It’s bad code to poll un-throttled. Could this be due to Plex’s UPnP error retry not rate limiting?
You could rate limit the SSDP polling (it does seem rather aggressive, imho) but that wouldn’t fix the issue. The very first poll result from the IGD running miniupnd immediately triggers the process loop in either liburi or the boost library. Only disabling UPnP on he IGD and restarting PMS stops it.
How do other apps deal with SSDP and liburi / boost responses? I haven’t used liburi so don’t know the nitty gritty details, but other apps that support network discovery don’t usually peg the CPU forever.
