Plex Performance - 100% CPU

    • OMV 2.x
    • Resolved
    • Plex Performance - 100% CPU

      Hello all,

      Sorry if there is a better place for this didn't see a dedicated troubleshooting subforum. Anywho, I am currently having an issue with Plex performance during normal playback and even worse when trans-coding. I am using te ASUSRock c2750 CPU/board that didnt really blink at multiple simultaneous 1080 transcoding on FreeNAS but now hovers around 40% when just doing normal file playback and pegs out when trans-coding a single stream. Also when I look under the CPU Performance tab I don't see any mention of multiple cores, didn't know if that was normal or not.

      OMV Version: 2.1.1.9
      Kernel: Backport 3.16
    • I have an ASRock Rack C2550D4I, the four core version of your eight core board.

      I see CPU running 70-80% on all four cores when transcoding.

      I don't see multiple cores in the CPU Performance tab either. htop will show all cores, so run that to see them.

      I don't think you have a problem, it's probably that FreeBSD and Linux might measure or display load differently.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • See that's the weird thing, I think you should be seeing much better performance than that. I personally tested 4 x 1080 trans-code streams to friends houses when running this exact same box on FreeNAS and it didn't hitch. Something is screwy somewhere and it is absolutely hamstringing performance.
    • No problems here on similar (but lesser hardware).

      I am also running the backport kernel with Crucial 16GB DDR3/DDR3L-1600MT/s (PC3-12800) DR x8 ECC UDIMM Server Memory.

      Streaming three movies that require both audio and video transcoding, I see on htop 24 instances of the Plex New Transcoder running, each consuming between 0 and 25% CPU with all four CPU cores @99-100% but no buffering or stutters. Memory usage is 972MB, swap usage is 0.

      OMV WebGUI is not quite as snappy but still very usable.

      Click on pic to see the whole thing.
      Images
      • rrd.png

        17.94 kB, 497×221, viewed 700 times
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • Ok did a bit more toying around, was running 3x 1080 steams with Audio/Video transcoding and was getting a lot of hitching. Watching HTOP all eight cores were bouncing between 60 and 100% utilization. ~1.8gb (of 16gb) memory in use and no swap. I did notice the CPU utilization would occasionally drop to 0 but then snap back up. Took gifs of the CPU usage:
      1Stream:
      recordit.co/XfswY4ldSX
      2Stream:
      recordit.co/P3PVpPoTRG
      3Stream:
      recordit.co/Rj4Fy8jwp7

      So for now looks like the most I can get out of this is 2x1080 stream with transcoding. Dont *think* it would matter but I am also running MergerFS but this looks to be a CPU issue specifically with the Plex processes.

      Heres the CPU graph when I was playing around:
      [Blocked Image: https://i.imgur.com/Zlwdp6v.jpg]
    • If you consult the page here:

      support.plex.tv/hc/en-us/artic…d-for-my-Server-computer-

      they suggest that to transcode a single 1080p/10Mbps strem, you need a CPU with a 2000 PassMark score.

      According to this site:

      cpubenchmark.net/cpu.php?cpu=Intel+Atom+C2750+%40+2.40GHz

      your CPU has a 3874 PassMark score, so three such streams should be OK.

      My CPU has a PassMark of 2329, well below yours. So I would expect to have big problems here trying what you are doing.

      Is/are the media you are streaming publicly available? I'd be willing to test here if I can get the files.

      You don't state what client you are using. I use a Roku 3 and almost all of my media requires no transcoding, so I would not expect to run into such problems. Given the choice, if a media file is available in a format that does not require transcoding, I take that instead of one that does. And I have in the past recontainerized (not transcoded) files just to avoid having to transcode. Re-containerizing takes seconds, while transcoding a file into a suitable format is very slow and not worth the bother to me.

      What are your options?
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380

      The post was edited 1 time, last by gderf ().

    • Honestly the thing that is causing the most issues is subtitles, since the video has to be transcoded on the fly to include them. If I dont use subtitles I have zero issues since most of my video collection plays natively on most of my players. The kicker is that this was never a problem under FreeNAS, ran perfectly there and could do 4 streams w/subtitles with no buffering, I am just sick of dealing with FreeBSD and all its quirks and the jails dying every time you look at it funny.
    • So here something potentially interesting, here's the HTOP while transcoding, difference being this is Plex installed through Docker and not as a OMV plugin:
      1Stream
      recordit.co/nF19mdrAGb
      3Streams
      recordit.co/oEArqzCWQd

      Seems to be drastically better performance using Docker, it still pegs out but then it calms down for a bit and overall playback is smooth. Wonder if someone could test as well?

      So far the only downside is the webGui for Plex seems flakey when installed through Docker but that's more than likely user error...

      Next Step: Figuring out how to move the xcode temp directory to RAM :)
    • mergerfs is a fuse filesystem which is most likely more cpu intensive than the FreeNAS filesystem (zfs?) and doesn't not have the throughput to support 3 or 4 HD streams (I'm guessing). A single hard drive typcially have more throughput than a fuse filesystem. I would curious to see how the system did with the files read from a single hard drive (or mdadm raid 5).
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      mergerfs is a fuse filesystem which is most likely more cpu intensive than the FreeNAS filesystem (zfs?) and doesn't not have the throughput to support 3 or 4 HD streams (I'm guessing). A single hard drive typcially have more throughput than a fuse filesystem. I would curious to see how the system did with the files read from a single hard drive (or mdadm raid 5).


      Ahhhaaaaa. So I think what is happening is that when I configured Plex initially I set it to use my MergerFS volume as its path for its database/files, including the transcode temp files. When I setup Docker it was using the default path, which was the USB stick OMV is installed to. I am guessing the extra overhead from reading/writing the trans-code temp files to the MergerFS is what is killing performance. I am going to try reinstalling Plex and just pointing it at a single drive instead and see what happens.
    • So I think I got this resolved. I reinstalled OMV to a new USB3 thumb drive and added a second USB3 drive as a place to land all the plugin directories instead of using the main MergerFS pool. I am not able to stream out 4x transcoded streams with no hitching. Watching HTOP all eight cores are are pretty much pegged at two streams but I kept adding more and it handled it fine not sure whats up with that but there it is. This is more in line with performance I saw running FreeNAS and ZFS but not using ZFS (YAY! Expandibility!).

      Lesson learned, UnionFS is for storage and storage alone :)

      Thanks for your time and help!
    • Brognak wrote:

      Lesson learned, UnionFS is for storage and storage alone :)

      Not quite true. aufs is a native linux kernel module and doesn't use fuse. So, it is quite a bit faster.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Brognak wrote:

      Lesson learned, UnionFS is for storage and storage alone :)

      Not quite true. aufs is a native linux kernel module and doesn't use fuse. So, it is quite a bit faster.


      D'oh. Shows how much I know. Now I am trying to remember why I was using MergerFS over aufs... New and shiny tends to attract my attention I suppose.

      gderf wrote:

      And I was getting ready to call dibs on your MB & memory when you (unnecessarily) upgraded to a Intel® Super-High-End® Xeon® machine :(nd I was getting ready to call dibs on your MB & memory when you (unnecessarily) upgraded to a Intel® Super-High-End® Xeon® machine 

      Glad you have it sorted.


      I *may* have a Amazon wishlist put together.... Seriously though, I can vouch for the C2750 this thing is a great piece of kit power/watt/price wise. The ASRock one is even better with a bajillion sata ports. Caveat: Performance claims do not apply to single threaded tasks. Its a dog in that area.


      edit: Holy CRAP aufs is fast in comparison. Maxed rsync transfer at ~300-400 mb on MergerFS and am now almost saturating the gig port on aufs...

      The post was edited 4 times, last by Brognak ().

    • Brognak wrote:

      edit: Holy CRAP aufs is fast in comparison. Maxed rsync transfer at ~300-400 mb on MergerFS and am now almost saturating the gig port on aufs...
      Yep, my backup server uses aufs and can saturate gigabit :)
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Author of mergerfs here. Gigabit ethernet is 125MB/s max theoretical. mergerfs should definitely handle that. The author of zackreed.me seemed to be getting over 110MB/s in his network tests. A quick test with mergerfs mounted over tmpfs shows native writes of 2.2GB/s and through mergerfs around 900 - 1000MB/s. With reads from native tmpfs around 5.4GB/s and through mergerfs around 2.9GB/s.

      Do you know how many files were open during your tests? What settings you had for mergerfs? aufs?

      There is a new feature possibly coming to FUSE that will probably allow near native speeds for mergerfs. I'll be supporting it as soon as it's available.

      The post was edited 1 time, last by trapexit ().