Michael_P

Every time one of your containers hits the limit it will be culled and logged, which FCP will detect and report every single time FCP scans the log, so you will need to reboot every time to clear the log. You can use the advanced tab to match the first 12 digits of the container ID'd in the log ie:

Immich is running the host OOM, 16GB is a little light if you want to run it with all of the rest of your services - you can try to tune it a bit or limit the RAM to the container but you should probably just add more RAM. When you've fixed or disabled Immich, you will need to reboot to clear the log so FCP stops warning you about it

Looks like on the 2nd and 18th of June Plex media scanner hit its memory limit and was killed. You can check the container logs to see if there's a file it doesn't like. Reboot to clear the log so FCP stops warning you

If it does it again, run ps -auxf > ps.txt from the command line and that should show you what's using it. Navigate to a folder share first so you can grab the ps.txt that it generates

Only if they ship it DDP, else it's on the IOR

and fees - MPF alone will be $103 and change, not to mention the carrier's fees to broker it for you (and tariffs if it's made in China).

Kate's a text editor so probably not related to watching plex - if it happens again you can run ps -auxf from the command line to see what process is kicking it off (krusader was running at the time, may have been in there)

Looks like on May 01 at 0915 and 0916 kate decided to use an absolute crap ton of RAM, so if you were doing something at that time then that's the issue. You can reboot to clear the log so FCP stops warning you, and if it happens again you can investigate further

Ok, you can use it to find out what's spawning the gunicorn and ruby processes, and either limit the RAM to that container or reduce your VM's allocation. Since the reaper is killing the VM each time (it's the largest consumer at the time the host starts to OOM), that would indicate that you just don't have enough RAM to run everything, so you can either add more (in this economy!?!) or reconfigure your services. Once you've done all that, you can re-boot to clear the log so FCP stops warning you

If I had to guess based on the processes running at the time, I'd say it was immich. Dump the result of ps -auxf to a file and post it, taking care to remove any passwords if they are included in your container's startup commands ps -auxf > ps.txt

Back on APR 12 one of your containers (8c565a95c675) hit its assigned limit and was killed. Looks like a one-off occurrence so you can reboot to clear the log so FCP stops warning you. If it happens again, you can check the container's config or assign it more memory

It's not actually running out of memory, it's a driver issue - update the driver and/or the motherboard BIOS

It's usually just a driver/BIOS issue, not something physically wrong with the card

It's actually your nvidia card falling over, FCP is reporting based on finding 'out of memory' in the syslog. Try updating the drivers and/or the motherboard BIOS Apr 11 03:08:00 nomad kernel: NVRM: nvCheckOkFailedNoLog: Check failed: Out of memory [NV_ERR_NO_MEMORY] (0x00000051) returned from _memdescAllocInternal(pMemDesc) @ mem_desc.c:1359

Looks like back on the 23 March whatever container matches this ID 7f7c77b7b0989 ran over its assigned limit and was repeatedly killed, then on the 24th it looks like you were running something that had ffmpeg doing work which tipped the host OOM so it stopped the highest consumer which at the time was your VM. Doesn't look like you need to do anything, so just reboot to clear the log and FCP will stop warning you