Plex RAM Transcoding

@ChuckPa In your Linux PMS RAM transcoding guide here, you specified this in /etc/fstab:

tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,size=64G,mode=1777 0 0

Just to make sure it’s not a typo, shouldn’t the mount point /tmp/transcoding instead of just /tmp? /tmp is already mounted during installation on the OS disk.

Also, do you have any recommendation as to how big of a RAM mount point I should create if I have 32GB of RAM and doing 4K transcoding?

/dev/shm is created automatically on linux and allocated 50% of your ram.

you should simply use that (/dev/shm/transcoding) instead of creating another tmpfs.

do note, the only real reason you should use ram transcoding is if you have only SSD os/plex data drive and want to avoid the write wear.

unless your hard drive is slow to be unusable, ram transcoding will not normally ‘increase your transcode performance’.

more likely, your cpu or upload speed is the bottleneck.

That was actually my next question as I’m reading that most people can use /dev/shm and yes I verified that it is indeed a 16G partition. Where is the rest of the RAM (the other 50%) assigned to? And what is the use of /dev/shm by design?

Yes, that is my exact purpose. I know it won’t really increases performance but I’m trying to avoid write wear on my SSD OS/Plex metadata drive.

Also, why does Plex themselves recommended the recommended space for the transcode folder is the original source file plus 100MB? What happens if you don’t meet this? I have 4K files that are 50GB and up, for sure.

google will tell you more about /dev/shm than I can.

I would imagine it is so that plex has enough space to pre-transcode a whole file, if necessary.

you also should consider when multiple transcodes are going, all of which must share the transcode space.

additionally, I believe the /transcode space is used for live tv/dvr functionality, so it can potentially limit how long or how many recordings can be done at the same time.

1 Like

If you only have a pitifully small temp folder, you can’t easily jump back, without the server having to transcode that previous part of the video again
If you have plenty of room for the transcoder temp folder, Plex will leave the previously transcoded chunks of a whole video in there, until you stop playback.
This is also important for pausing and resuming of live TV playback.

1 Like

I see. So I guess it’s still better to monitor my server’s actual usage. I don’t use live TV or DVR, so no issues on that. I don’t think the seeking during playback will also be a problem. I’m fine if it transcodes that part of the video again.

It is additionally used temporarily for sonic analysis if that is enabled as well

Which one, the transcoding folder of Plex? Yeah, I don’t do Music in Plex.

So I’m using dev/shm for Plex RAM transcoding and it’s filling up my 32GB available RAM. Just now, I saw the folder reaching 28GB. I thought it’s supposed to be just up to 50% of RAM?

@kevindd992002

Maybe a typo, please confirm /dev/shm ( leading ‘/’ is important )

Also please show a /bin/df -h before and when the transcoder is running.

Yes, sorry, that was a typo. This is exactly what I used: /dev/shm/transcoding and this is what I was getting in cockpit:

image

When I deleted that folder, the plexmediaserver RAM usage went down to 137MB.

/bin/df -h before transcoding:

Filesystem                      Size  Used Avail Use% Mounted on
udev                             16G     0   16G   0% /dev
tmpfs                           3.2G  3.3M  3.2G   1% /run
/dev/nvme0n1p2                   23G  5.3G   17G  25% /
tmpfs                            16G  4.0K   16G   1% /dev/shm
tmpfs                           5.0M     0  5.0M   0% /run/lock
/dev/sda1                       1.8T  983G  757G  57% /mnt/storage
/dev/nvme0n1p5                  1.9G  6.0M  1.7G   1% /tmp
/dev/nvme0n1p3                  9.2G  3.1G  5.6G  36% /var
/dev/nvme0n1p6                  193G   18G  166G  10% /home
/dev/nvme0n1p1                  511M   18M  494M   4% /boot/efi
overlay                         193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/2b4ffcf1b7702731839ac1ac6613e7c1adba4a87c6fa80bd4f7a4842fcd4fd51/merged
overlay                         193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/e566b3ccbf13c13b5f43b51f0b35adcb6179a3d93d56f8aa0f4fee98f7698a71/merged
overlay                         193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/7cce9c6f8eb3c679747273cd0bfad7585dc37c436d1610bdde7b02cfc6146790/merged
//synology.home.arpa/NetBackup  104T   65T   40T  63% /mnt/RoonStorage_fec9d551e282a1324d0021bbfccbfba931234b4c
overlay                         193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/9321b90e2003c56fa22743670a5ce65923ee139dc64cf9ec3c2f17291915817e/merged
tmpfs                           3.2G     0  3.2G   0% /run/user/1000

Here’s during transcoding:

root@nuc:~# /bin/df -h
Filesystem                        Size  Used Avail Use% Mounted on
udev                               16G     0   16G   0% /dev
tmpfs                             3.2G  3.3M  3.2G   1% /run
/dev/nvme0n1p2                     23G  5.3G   17G  25% /
tmpfs                              16G  454M   16G   3% /dev/shm
tmpfs                             5.0M     0  5.0M   0% /run/lock
/dev/sda1                         1.8T  983G  757G  57% /mnt/storage
/dev/nvme0n1p5                    1.9G  6.0M  1.7G   1% /tmp
/dev/nvme0n1p3                    9.2G  3.1G  5.6G  36% /var
/dev/nvme0n1p6                    193G   18G  166G  10% /home
/dev/nvme0n1p1                    511M   18M  494M   4% /boot/efi
overlay                           193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/2b4ffcf1b7702731839ac1ac6613e7c1adba4a87c6fa80bd4f7a4842fcd4fd51/merged
overlay                           193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/e566b3ccbf13c13b5f43b51f0b35adcb6179a3d93d56f8aa0f4fee98f7698a71/merged
overlay                           193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/7cce9c6f8eb3c679747273cd0bfad7585dc37c436d1610bdde7b02cfc6146790/merged
//synology.home.arpa/NetBackup    104T   65T   40T  63% /mnt/RoonStorage_fec9d551e282a1324d0021bbfccbfba931234b4c
overlay                           193G   18G  166G  10% /home/kevindd992002/docker/var-lib-docker/overlay2/9321b90e2003c56fa22743670a5ce65923ee139dc64cf9ec3c2f17291915817e/merged
tmpfs                             3.2G     0  3.2G   0% /run/user/1000
tmpfs                             3.2G     0  3.2G   0% /run/user/0
synology.home.arpa:/volume1/data  104T   65T   40T  63% /mnt/data

I don’t get why it just says 454MB there but it says around 8GB in Cockpit for the plexmediaserver service. I tried not using /dev/shm and have Plex use the default tempdr in my custom config:

# Change TMP directory for transcoder
Environment="TMPDIR=/home/plex/Transcode"

And when I check Cockpit, I see that it still uses a significant amount of RAM (4GB now). Does that mean Plex uses RAM for transcoding regardless of the transcoder temp directory configured?

@kevindd992002

Which “Plex uses RAM” are you speaking of? VIRT or RES?

   1977 root      20   0 3165040  20816   4104 S   3.8   0.0   2:34.89 snapd                                                    
 911424 plex      20   0 4768212  95068  17028 S   1.0   0.0 173:36.72 Plex Media Serv    

I’m honestly not sure because I’m basing my claims off of Cockpit. Are you familiar with Cockpit? If you see my post above, it says that plexmediaserver has 28.8GB used but then the bar graphs above show that I still have 29.8GB available physical RAM.

@kevindd992002

I use Cockpit but don’t have any listing for /dev/shm nor do I expect to see it.
/dev/shm is a kernel virtual filesystem which is constructed and destructed as needed.

As you can see here, the transcoder creates /dev/shm/Transcode itself when first used. It remains until kernel restart.

[chuck@glockner ~.1997]$ cd /dev/shm
[chuck@glockner shm.1998]$ ll
total 4
drwxrwxrwt  5 root root  120 Apr  5 00:26 ./
drwxr-xr-x 22 root root 5640 Apr  5 02:02 ../
-rw-r--r--  1 plex plex   32 Mar 27 14:50 9334581e-7251-4ef7-a8ec-5bfe8e89ff68
drwx------  4 root root   80 Mar 26 15:07 multipath/
drwxr-xr-x  3 plex plex   60 Mar 26 15:23 Transcode/
drwxr-xr-x  2 emby emby   40 Mar 27 16:11 transcoding-temp/
[chuck@glockner shm.1999]$ du -ms *
1	9334581e-7251-4ef7-a8ec-5bfe8e89ff68
du: cannot read directory 'multipath': Permission denied
0	multipath
0	Transcode
0	transcoding-temp
[chuck@glockner shm.2000]$ 

I don’t understand why you’re using TMPDIR unless you’re wanting to take the temporary png and jpg files out of /tmp ?

I have 1045 of them and total use is 500MB for everything in /tmp. (posters)

[chuck@glockner tmp.2012]$ !ll
ll *.jpg | wc -l
1045
[chuck@glockner tmp.2013]$ sudo du -ms .
517	.
[chuck@glockner tmp.2014]$

I see. I guess I’m just trying to understand what the plexmediaserver usage means? Right, now I’m transcoding three different 4K streams to 720p just to simulate and this is what I get in Cockpit:

image

And for /dev/shm:

root@nuc:~# du -sh /dev/shm/*
4.0K    /dev/shm/9334581e-7251-4ef7-a8ec-5bfe8e89ff68
1.5G    /dev/shm/transcoding

So that’s just 1.5G worth of space in /dev/shm but why does it say 26.1GB “used” in Cockpit? And 24.5G available. The numbers do not add up unless I’m missing something?

As for TMPDIR, I used that to put my transcode folder to /home/plex instead of /tmp because my tmp folder is rather small. But since I’m using /dev/shm for my transcode folder now, should I remove the TMPDIR entry in my custom config?

Thanks for clarifying.

Where do you find that detailed display in Cockpit?

The closest I can get is this:

which matches this:

[chuck@lizum ~.2004]$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64232       12271        6445         291       45515       50972
Swap:         61034           3       61031
[chuck@lizum ~.2005]$ 

System → Overview → Usage → Memory

Which version do you have? I don’t see the chart you posted on my Cockpit. I’m using 266.

@ChuckPa were you able to check on this?