Will moving to dual xeon be faster (does Plex make good use of many cores?)

I’m currently running plex on my homegrown NAS which is a core i7 860 (Lynnfield with 12gig ram). it’s a 4 core part with HT. I’m looking to move to a dual cpu xeon e5-2670. Those units have lower single thread passmark score than my core i7 but much higher overall passmark score. Also, they are 8 core with HT so a dual cpu system would have 32 “cores” available. I’m also running docker and TVHeadend on that system.

I’m trying to find out if the great “core” count will bring improvements even though it’s lower single thread performance. I would also have more memory – likely 32 gig.

Thoughts?

Compare the Passmarks:

https://www.cpubenchmark.net/cpu.php?id=6
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2670+%40+2.60GHz

PMS will make use of as many as you have.
If transcoding, the per-thread speed becomes more important than more cores for some operations like subtitles (single threaded).

IMHO, running PMS in Docker on Linux is equivalent to wrapping yourself in plastic wrap. Docker presents a Linux environment. You’re already native on Linux. No net gain. Hardware transcoding is automatic on Linux if you have the CPU/GPU. It’s not in Docker. Backups / relocation in Linux uses a tarball. Docker is a full export / import operation which isn’t always as portable as claimed.

@ChuckPA said:
Compare the Passmarks:

PassMark - Intel Core i7-860 @ 2.80GHz - Price performance comparison
PassMark - Intel Xeon E5-2670 @ 2.60GHz - Price performance comparison

PMS will make use of as many as you have.
If transcoding, the per-thread speed becomes more important than more cores for some operations like subtitles (single threaded).

IMHO, running PMS in Docker on Linux is equivalent to wrapping yourself in plastic wrap. Docker presents a Linux environment. You’re already native on Linux. No net gain. Hardware transcoding is automatic on Linux if you have the CPU/GPU. It’s not in Docker. Backups / relocation in Linux uses a tarball. Docker is a full export / import operation which isn’t always as portable as claimed.

it’s no surprise why people like to use Docker in cases like this. It isolates the dependencies from the main system so i can run tvheadend, emby, plex, etc, etc without conflicting resources/libs/etc. This is very clean. However, if running PMS in docker causes it to run less than optimally I would love to know that. Is there some writeup that compares Plex on and off docker? I’d like to know more about what is slower/harder in Docker?

Actually I guess I had more numbers wrong. The E5-2670 has faster single thread than core i7 860 so it’s better in all scenarios :slight_smile:

I would still like to see a breakdown of pros/cons of using Plex in docker if anyone has a link to something like this.

"Isolation from dependencies " is a vague statement and incorrect. PMS brings all the libraries it needs with it except those fundamental to base OS operation (e.g glibc, SSL, TCP/IP).

On a NAS, using Synology as example, the vendor only provides what’s needed for the NAS functions to work. The app (PMS) must bring everything else it needs. PMS brings everything with it. In that docker image you’ll find ALL the dependencies PMS needs to operate.

On desktop Linux, look in /usr/lib/plexmediaserver. You will find those dependent libraries. PMS doesn’t make you install ‘a zillion other things’ first. It brings everything with that it needs except the codecs. That’s why the download size is so large. If it brought the codecs (which it can get on-demand when running) with it, it would be about 3x larger. Not everyone needs all the codecs so why burden everyone with that much extra space utilization?

Full ports list as copied from the firewall page.

TCP: 32400 (for access to the Plex Media Server) [required]
The following ports are also used for different services:

UDP: 1900 (for access to the Plex DLNA Server)
TCP: 3005 (for controlling Plex Home Theater via Plex Companion)
UDP: 5353 (for older Bonjour/Avahi network discovery)
TCP: 8324 (for controlling Plex for Roku via Plex Companion)
UDP: 32410, 32412, 32413, 32414 (for current GDM network discovery)
TCP: 32469 (for access to the Plex DLNA Server)

Bottom line: Docker is a technology which can be leveraged when there is no native support but it’s no substitute for a native solution.

@ChuckPA said:
"Isolation from dependencies " is a vague statement and incorrect. PMS brings all the libraries it needs with it except those fundamental to base OS operation (e.g glibc, SSL, TCP/IP).

On a NAS, using Synology as example, the vendor only provides what’s needed for the NAS functions to work. The app (PMS) must bring everything else it needs. PMS brings everything with it. In that docker image you’ll find ALL the dependencies PMS needs to operate.

On desktop Linux, look in /usr/lib/plexmediaserver. You will find those dependent libraries. PMS doesn’t make you install ‘a zillion other things’ first. It brings everything with that it needs except the codecs. That’s why the download size is so large. If it brought the codecs (which it can get on-demand when running) with it, it would be about 3x larger. Not everyone needs all the codecs so why burden everyone with that much extra space utilization?

Full ports list as copied from the firewall page.

TCP: 32400 (for access to the Plex Media Server) [required]
The following ports are also used for different services:

UDP: 1900 (for access to the Plex DLNA Server)
TCP: 3005 (for controlling Plex Home Theater via Plex Companion)
UDP: 5353 (for older Bonjour/Avahi network discovery)
TCP: 8324 (for controlling Plex for Roku via Plex Companion)
UDP: 32410, 32412, 32413, 32414 (for current GDM network discovery)
TCP: 32469 (for access to the Plex DLNA Server)

Bottom line: Docker is a technology which can be leveraged when there is no native support but it’s no substitute for a native solution.

I suppose I was not as clear as I could be. By saying isolation from dependencies I’m talking about the ease of support of dependencies in general. For example. emby installs a ton of libraries. Rather than deal with all of that it’s much easier to simply “docker run emby” to fire up a container. Want to try out a beta version of plex while not interfering with a production copy of plex? Sure, np!

Docker has plenty of uses in a native home environment (albeit geeky home – most folks are not running a NAS let alone docker).

So, that being said – if you told me that plex works just as well in a container as it does directly on the OS then I would run it in a container. If there are some benefits (better transcoding due to access to the GPU, etc, etc) to being natively on the OS then I’d like to know that too.

Iv’e posted in the docker forum about this as well.

Want to try out a beta version of plex while not interfering with a production copy of plex? Sure, np!

That’s not your original requirement. Docker still uses the native resources if in --net. If you want it in a NAT to play with, then YES, it’s a safe place to play but that’s it. In that use case, it’s providing the encapsulation (plastic wrap) needed to make cleanup easy.

I see your post in Docker. You’ll still have to map the GPU if you want it to work (udev passthrough is not supported by the container so you’ll need that magic yourself)

Moving this thread to General as it is not a Linux-specific issue.