silversrfr

To reinforce @rcmpayne above... as per @Squid : ISOLCPUS works by preventing the OS from utilizing certain cores. Since Docker runs directly as processes on the OS, then it only has access to the cores that you've assigned specifically for unRaid use. Therefore if you want Plex to utilize all of the cores available to unRaid, it is pointless to add in the cpuset-cpus parameter to plex as you've implied you did by stating you assigned the cores to Plex. And by your example, your assigning Plex access to cores that it doesn't have access to since the OS doesn't have access to it. A docker, although similar to a VM is not a VM and is constrained by the limits imposed firstly by the OS and then secondly by the parameters passed to it in the template.

I have the same issue with my plexinc/Plex docker, multiple pinned CPU cores but only one core (the first in the string of CPUs) is being utilized at as high as 100%. I actually noticed this first when running Snoopy's Unbuntu docker. If I changed the CPU cores specified by cpuset-cpus, the single core being used at a high percentage moved to whichever CPU I assigned first in the list. I suspect this is the same for any docker I have pinned CPUs to, but they just don't use a high enough processor for me to have noticed. I have an HP DL389 g6 One thought... My HP Unraid server had the processors listed incorrectly in older (6.3.x) Unraid versions. However, pinned CPU usage was normal (distributed accross all pinned cores assigned by cpuset-cpus) for me prior to upgrading unraid to 6.4.1. Is this pinning issue related to whatever was done to fix the old CPU "mapping" issue?

It's my understanding that the socket error is a Java Client issue. Specifically it's an issue in the Paho client which other apps (such as owntracks) use.