I recently started seeing out of memory conditions every night in my syslog since October 6, 2026. Using 7.3.2 while I wait to be comfortable enough to go to 7.3.3.

It seems to be a different process each time but mostly Plex transcode. I have 32GB of RAM and a fairly modest(compared to others here) set of containers(Nextcloud, Immich, Arrs, a few others but nothing crazy).

I rebuilt my Plex database index per some suggestions. I also added the parameters to limit RAM usage(Extra Parameters = --device=/dev/dri --mount type=tmpfs,destination=/tmp,tmpfs-size=4000000000 --no-healthcheck --memory=4g).

Here is the memory usage right after a reboot:

And then in the morning:

And then I see another OOM condition in the logs in the morning.

Any suggestions?

flores-diagnostics-20261019-0844.zip

The OOMs have two causes that add up.

First, rootfs is 98% full (about 15.5GB used after less than a day of uptime). That is the high "System" RAM you see on the dashboard. Something is writing files to a path that is not on a disk or pool, so they are stored in RAM until the next reboot. Before your last reboot it was already holding around 12GB.

Second, every night between 3 and 5 AM, Plex Transcoder was growing to around 14GB. Together with the 12GB in rootfs, that is more than your 32GB, so the kernel killed the transcoder. Your new --memory=4g limit is working: last night only Plex was killed, at its own 4GB limit. But the rootfs usage is still there.

The most likely writer is your "My backup script" user script. It normally takes 11 to 20 minutes, but its first run after the reboot took almost 5 hours, and rootfs was full the next morning. That looks like a backup copying to a destination that is in RAM. To confirm, please post the output of:

df -h /

du -xhd1 / 2>/dev/null | sort -h | tail -15

find / -xdev -type f -size +500M 2>/dev/null

Also check the destination paths in that script. Anything not under /mnt/diskX, /mnt/cache, /mnt/user or a mounted /mnt/disks/... device is in RAM. A typo or a wrong capitalization in a /mnt/disks/... path, or a run while that disk is not mounted, will also write to RAM. You can check a path with findmnt -T /path/to/destination. It should show a disk or pool, not rootfs.

Once the destination is fixed, delete the files it left in rootfs (or reboot), and the RAM will be released.

Thanks for the quick response @JorgeB !

I'll take a look at my backup script, but in the meantime, here is the info you requested:

root@flores:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G   16G  442M  98% /

root@flores:~# du -xhd1 / 2>/dev/null | sort -h | tail -15
0	/home
0	/mnt
0	/opt
14M	/bin
17M	/etc
21M	/tmp
25M	/sbin
48M	/lib64
53M	/lib
577M	/var
15G	/root
16G	/

root@flores:~# find / -xdev -type f -size +500M 2>/dev/null
root@flores:~#

That confirms it: almost all the 16G in rootfs is under /root, which is the root user's home folder and lives in RAM. And there are no single large files, so it looks like a file-by-file copy (like rsync) ended up there instead of on your backup disk. That also fits the first backup run after the reboot taking almost 5 hours, because it had to copy everything again.

To see exactly what it is, please post:

du -xhd2 /root 2>/dev/null | sort -h | tail -20

Then check the destination paths in "My backup script". Common cause is a path missing the leading slash, e.g. mnt/disks/backup instead of /mnt/disks/backup. A path like that is relative to the current folder, which can be /root.

I think I might have found the problem. I don't think the backup destination was set to automount. Plus, I had upgraded borg to 1.4.5. So I formatted the backup drive, set it to automount, recreated the borg repositories, and I'm now running a backup using my script.

So far, so good.

It'll take a while to complete plus it'll run overnight. It might not finish by the time cron calls the backup again but it'll skip it if it's running already.

I didn't know that Unraid uses RAM if it doesn't find a disk in a script. Kinda weird. I'd expect it to error out.

I'll check back in a few days to confirm all is well. Thanks again for the help!

13 hours ago, nraygun said:

I didn't know that Unraid uses RAM if it doesn't find a disk in a script. Kinda weird.

Not really weird if you keep in mind that linux uses a "flat path" (compaired to a device path like used by windows).

So everything is "below /" (root), at some points, devices are "mounted" and take over the exising directory in root.

But if a mount fails or is missing somehow, the path still points to root.

And in UNRAID root is setup into a RAM Disk, so actually you are filling RAM now.

I think the backup script completed yesterday(~6.5 hours) and then ran again overnight.

The memory display on the dashboard looks good, but I still got a OOM in the syslog. Looks like the Plex transcoder did it again(Killed process 1347824 (Plex Transcoder)). I'm not even sure what or why it's transcoding at almost 3 in the morning.

Here's the output of the command @JorgeB requested along with a fresh diagnostic. I think the /root sizes look OK to me now.

root@flores:~# du -xhd2 /root 2>/dev/null | sort -h | tail -20
4.0K	/root/.config/sakura
32K	/root/.config/borg
36K	/root/.config
150M	/root
150M	/root/.cache
150M	/root/.cache/borg

flores-diagnostics-20261020-0955.zip

Yes, those /root sizes look normal now. The new diagnostics also show rootfs at only 6% used, so the earlier RAM-backed filesystem problem appears resolved, I'm not familiar with Plex, but it may be doing some maintenance task at that time; you can try giving it a little more RAM.

Thanks for taking a look.

I'm going to turn off a feature that some say may be the problem: Generate intro video markers

I also updated Plex.

Fingers crossed...

I still get OOM messages in the log due to the Plex Transcoder. I turned off a few more features(volume leveling) and saw that it was processing a movie when I logged in this morning.

I'll give it 8GB too and see what happens.

The overall system memory seems to be much lower than we started, so that's good.

Good news - no OOM this morning!

I turned off a few features of Plex including ‘Generate intro video markers’, 'Generate credits video markers', 'Generate voice activity data', 'Analyze audio tracks for loudness'.

I might put the transcode directory on a HDD and turn these features back on in the future.

Will monitor for a few more days, but now my logs look normal.

Well, I changed the transcode directory to use the array and turned on some of the features that rely on transcoding(like Intro Skip).

I got another OOM this morning.

I think the transcoding is just eating up memory. So I'll turn these features off again and monitor.

18 hours ago, nraygun said:

Well, I changed the transcode directory to use the array and turned on some of the features that rely on transcoding(like Intro Skip).

I got another OOM this morning.

I think the transcoding is just eating up memory. So I'll turn these features off again and monitor.

It might be choking on a particular file - if you've added any around the time the OOMs started you can start there. The plex log might also offer clues as to the last files it was working on

Well, the good news is I didn't get an OOM this morning. I have this in Extra Parameters: --mount type=tmpfs,destination=/tmp,tmpfs-size=16000000000 --no-healthcheck

The bad news is that memory usage spikes such that there was about 254MB of system RAM at one point overnight.

I think Plex just uses lots of resources when it does its transcoding. My old system at 64GB of RAM. This new server has 32GB.

I'll let it run for a few days and see how it goes. I might just have to turn off the features that use transcoding.

If you're using the latest qbittorrent you might want to watch that too. Reports of using over 10GB of RAM. Some sites already have blacklisted that version.

1 hour ago, strike said:

If you're using the latest qbittorrent you might want to watch that too. Reports of using over 10GB of RAM. Some sites already have blacklisted that version.

Thanks, I'll keep an eye on it. I'm on qbittorrent 5.3.0 and I haven't seen an OOM caused by it yet.

Another day without an OOM in the logs!

And another instance of very low free memory. I think I just need to find the right combo of features and memory usage.

I'll turn off the audio processing and see what happens.

I think I'm good to go.

Plex uses more memory due to new features that have been introduced in the last month or so that cause transcoding. I'm starting to see others that have the same problem I did.

https://forums.plex.tv/t/audio-enhancements-boost-dialog-normalize-loudness/942925

I turned off "Analyze audio tracks for loudness" and now I don't get OOM conditions daily like I was since early October.