Unsolved
This post is more than 5 years old
19 Posts
0
23505
Plex Media Server on 32bit Ubuntu on ESX 3.5 on 2800.
System specs:
CPU: Dual Core Xeon 2.8 GHz Paxville x1
RAM: 6 GB
HDD: SCSI 10k 73 GB x1
Motherboard: Foxconn XC320
So, here's my issue.
I've got ESX 3.5 installed on this box with an Ubuntu Server 12.04 client on the ESX Hypervisor. I've installed Plex Media Server and upgraded the OS and the PMS. Plex usually has no issues playing anything I throw at it but recently I've been finding files that PMS must trans-code before it can play. This led to constant buffering every 5-10 seconds. I thought it was the network so I ran an Ethernet cable. I thought it was the RAM so I allocated more to the VM. I thought it was the CPU so I upgraded from a single core 3.0 to a dual core 2.8. I'm out of ideas.
Do I need to install a physical video card in this thing so it can trans-code through the GPU? Can the CPU just not keep up? I've looked at the performance tab in the VMWare infrastructure Client and it appears that the CPU has a little bit of wiggle room while trans-coding the video.
DELL-Jonathan S
153 Posts
0
February 14th, 2013 18:00
Thanks for the great details on your setup and the graph. I would be really surprised if that CPU was capable of transcoding at playback speeds except at very low bit rates. To make things as fast as possible with your current setup, in addition to assigning the Ubuntu VM both CPUs, I would also make sure that all other VMs are powered off during transcoding. The 8G servers such as the 2800 did not support hardware virtualization, so if two virtual CPUs is still not fast enough, then you may want to consider doing a bare-metal OS install, or even just test transcoding while booted into a live CD. ESX 3.5 did not support PCI passthrough so you would not be able to offload processing to a GPU even if one were installed, unless the it was a bare-metal installation. Your best bet in this situation might be to transcode your media prior to streaming, unfortunately. Let us know if you try anything out and what the result is. Thanks for choosing Dell!
skinnyveganboy
19 Posts
0
February 15th, 2013 12:00
Well, it is capable of transcoding some files. I play the files on my Roku; I select "Direct Play" but most videos are not supported by the "Direct Play" mode so I have to select transcode. It usually plays fine 90% of the time and I never get any buffering except for the initial buffer but sometimes I play a movie that needs to buffer every 5-20 seconds for about 5 seconds or so. I have noticed that filesize seems to play a part in whither or not a movie needs to buffer. files that are 1.8GB in size or less seem to have no issues while files that are greater than 2GB have buffer issue. What's extremely odd is that I get less buffering of these larger files when I select a large viewing format (20Mbps 1080p). I don't understand. My thought was that it was closer to the the original file and therefore had to process less. Any thoughts?
DELL-Jonathan S
153 Posts
0
February 15th, 2013 13:00
Interesting. It sounds like it might be swapping. You can actually check on what is going on by installing the sysstat package if it is not already installed and then run a command like this:
$ sar -o transcoding_activity_report 5
This will log all available system activity data at five second intervals, indefinitely. Once that starts, begin transcoding/streaming one of the smooth/non-buffering media streams and let it run for a minute or so to establish an activity baseline. Then, stop that and start one of the choppy/buffering ones and let it go for a minute or two, long enough to span several of buffering behavior cycles. Then you can hit Ctrl+C to interrupt sar and review all the data with:
$ sar -f transcoding_activity_report -A
Or to just look at the paging behavior in particular with:
$ sar -f transcoding_activity_report -B
I might be wrong about the cause of the behavior (paging) but the -A report should have some outliers and patterns that identify a subsystem or parameter experiencing activity correlated to the buffering which can help narrow down the source of the problem.
Let us know what you find out!
skinnyveganboy
19 Posts
0
February 15th, 2013 18:00
Here's the output of those commands:
Video Buffers all the time
$ sar -o transcoding_activity_report 5
Video Plays fine
$ sar -o transcoding_activity_report 5
Video Buffers all the time
Video Plays fine
$ sar -f transcoding_activity_report -B
DELL-Jonathan S
153 Posts
0
February 18th, 2013 09:00
So if you crop this down a bit it's clear there is a notable difference in the memory access profiles of the two run types and this is most likely a consequence of the transcoder's media-specific behavior. If I had to guess, the increased %system in the buffering-all-the-time run is directly related to the fault/s and pgpfree/s which are consistently much higher (by a full order of magnitude) than the non-buffering run. This could be perhaps due to memory-intensive codec operation. The Plex FAQ states that transcoding is CPU-bound ( wiki.plexapp.com/.../FAQ:_Plex_Media_Server_and_NAS ) which is generally true and I really think that a faster CPU is what will make the difference here. Also if you have assigned 4 virtual CPUs to the VM and you only have two physical cores with hyperthreading, you may want to just give it 2 virtual CPUs and see if that changes anything, or if the transcoder is single-threaded then maybe just one CPU might actually be best. Hyperthreading and similar technologies can be effective in a virtual environment for I/O-bound workloads but I would stay away from them for CPU-intensive tasks such as transcoding. In fact virtualization in general adds unnecessary overhead that limits CPU-bound applications (although it is certainly great for I/O- and memory-bound applications). It might be helpful to compare your setup to others' who are successfully able to transcode the same media you are struggling with to get an idea of what CPU is best suited for that.