Time to Deprecate Plex VM

I’ve been running Plex since 2017 and for all this time it has been installed in an Ubuntu Virtual Machine via a Deb Package. This has been extremely reliable and I’ve been able to upgrade the underlying Ubuntu distribution and Plex versions without issue.

The basic Virtual Machine has remained relatively unchanged over time with the following specs:

• 8 vCPU (8 CPU cores given to Virtual Machine)
• 8 GB virtual Memory
• 30 GB virtual Storage Disk (4 Disk ZFS RAID 10 SSD array)
• Media mounted via NFS (was SMB prior to Windows 2012 R2 File Server decommission) to HDD NAS (4 Disk Btrfs RAID 6 array)

As the underlying Virtual Machine host has lots of CPU cores available I have never added a GPU for Transcoding, opting to just keep adding CPU cores as required.

In my last post Windows 2012 R2 Decommission I mentioned about a problem that would change my whole architecture.

Transfer Speeds

Whilst copying all the data over Samba from my M1 Max MacBook Pro over Gigabit Ethernet and having the Plex server access the files using NFS over Gigabit Ethernet it seemed like everything was going perfect. Transfer speeds of > 100MB/s were achievable in both directions.

However, over Wi-Fi connecting over Wireless AC I was only getting around 10MB/s. Transfer speeds to the old Windows 2012 R2 server over Wi-Fi were about 40-45MB/s. Nothing else in the network had changed.

My NAS/File Server has gone through multiple iterations after the years so it’s interesting to know the reasons for each iteration and the reason why I’m migrating it once again.

First File Server (Ubuntu 11.10)

My first NAS implementation was an old desktop PC running Ubuntu 11.10 that was running samba. I didn’t know about using RAID/mdadm at that time so it used a single 2TB hard drive that would mirror itself with rsync to another 2TB hard drive nightly.

Upon migrating my blog to a Google Cloud Compute Engine VM (this very blog) I had a strange issue where it would freeze and become unresponsive. Only “Resetting” the VM would bring the blog back.

The findings were so interesting I thought I would share them.

Issue

It’s worth noting what the instance is (and importantly what resources it has been allocated) as it probably would not be an issue with a larger (and more expensive) instance. As of writing the instance is set to a “e2-micro” instance located in “us-central1”. The reason for this is you get one free instance in this region when using Google Cloud.