-
Posts
636 -
Joined
-
Last visited
Recent Profile Visitors
2783 profile views
Michael_P's Achievements
-
Whatever Immich is doing is running the system out of RAM - left unrestricted, any container can use whatever system resources it has access to. You can limit the container's available RAM in the advanced settings, but that won't solve whatever the container is doing to run itself out of RAM. As for why Immich is chugging down all that RAM, I can't help you there - you can ask in the container's help thread or try to get help on Immich's site
-
Best Unraid Backup and what exactly am I backing up???
Michael_P replied to Smokie's topic in General Support
Depends on how critical the data on the server is. If you don't have the capacity to back up the entire system, then figure out what data you can't afford to lose. I use this script in conjunction with the appdata backup plugin -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/ -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
Cant help you there, but I'd suggest a reputable brand from a reputable seller - there's a lot of shadiness in the world of flash drives. From what I remember, a 16/32GB USB 2.0 device is what's usually what's recommended but don't quote me on that -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
try another port, or retry creating the USB -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
No worries I'm not familiar with Frigate so I can't tell you where exactly to go, but in its settings or config file there should be storage folders and working folders, make sure that wherever ffmpeg is set to place its work files (which briefly looking at the docs appears it may be /tmp/cache) is either limited or mapped to a disk folder -
Seeking NAS Solutions: Advice Needed for Small Operation
Michael_P replied to Kiara_taylor's topic in Lounge
It's well enough known to anyone that 'competently runs NAS and network', but you know that. Here's the citation for those that don't (straight from CISA): https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
Make sure it's not configured to transcode to a directory that isn't mapped to a drive -
Keep getting this error (Your server has run out of memory)
Michael_P replied to LugoCloud's topic in General Support
Here's the container that was running the process, see if any part of the string matches either of the container IDs (advanced view on the docker tab) - Frigate is the most likely as there were quite a few processes running at the time (via coral/cuda-EvtHandlr), and on the 10th it was Frigate capture that invoked the reaper (each time ffmpeg ran away with the RAM) Most likely Frigate: 42895499d47e566044b88aaad34d27527654e862a99663365824e302465beb4d Whatever you're using for GPU offload: 130189b80344b2fc2eb03b176497c5eba0aa27c18268a83afec3ba62771debc9 -
Seeking NAS Solutions: Advice Needed for Small Operation
Michael_P replied to Kiara_taylor's topic in Lounge
unRaid or RAID(1,5,10,whatever) does absolutely nothing to protect data. RAID is for maintaining uptime - period. It doesn't take a catastrophe to cause data loss, a simple press of the delete key is sufficient. That's why an actual, tested, backup strategy is critical for critical data. 3 copies, 2 on different media, and 1 offsite is the standard. -
Check your immich config, looks like maybe it's the issue
-
Nothing reported in the logs, I'm not sure what FCP checks for but it may be flagging this line Mar 6 15:52:31 PrecisionRig emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/showLog.php Out of Memory Check
-
It looks like the Frigate container running an ffmpeg process - the VM's processes wouldn't be separately visible (they'd all be contained in the VM) Mar 4 04:03:19 Andromeda kernel: [ 6380] 0 6380 293668 24347 483328 0 0 frigate.logger Mar 4 04:03:19 Andromeda kernel: [ 6430] 0 6430 395035 33985 782336 0 0 frigate.recordi Mar 4 04:03:19 Andromeda kernel: [ 6449] 0 6449 3564 1318 61440 0 0 python3 Mar 4 04:03:19 Andromeda kernel: [ 6451] 0 6451 398660 28977 581632 0 0 frigate.detecto Mar 4 04:03:19 Andromeda kernel: [ 6455] 0 6455 496288 27344 638976 0 0 frigate.output Mar 4 04:03:19 Andromeda kernel: [ 6459] 0 6459 31705 2264 159744 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 6495] 0 6495 31705 1764 163840 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 6510] 0 6510 31705 1763 163840 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 6541] 0 6541 31705 1763 167936 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 6561] 0 6561 31705 1752 155648 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 7173] 0 7173 537950 39200 753664 0 0 frigate.process Mar 4 04:03:19 Andromeda kernel: [ 7174] 0 7174 537886 39269 753664 0 0 frigate.process Mar 4 04:03:19 Andromeda kernel: [ 7178] 0 7178 540778 42136 774144 0 0 frigate.process Mar 4 04:03:19 Andromeda kernel: [ 7179] 0 7179 542982 44344 794624 0 0 frigate.process Mar 4 04:03:19 Andromeda kernel: [ 7180] 0 7180 437282 33519 602112 0 0 frigate.capture Mar 4 04:03:19 Andromeda kernel: [ 7181] 0 7181 432781 33462 622592 0 0 frigate.capture Mar 4 04:03:19 Andromeda kernel: [ 7182] 0 7182 433060 35446 638976 0 0 frigate.capture Mar 4 04:03:19 Andromeda kernel: [ 7183] 0 7183 443746 35576 638976 0 0 frigate.capture Mar 4 04:03:19 Andromeda kernel: [ 7226] 0 7226 123878 11583 421888 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 7272] 0 7272 33524 3110 192512 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 7312] 0 7312 33272 4360 184320 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: [ 7321] 0 7321 32862 3458 196608 0 0 ffmpeg Mar 4 04:03:19 Andromeda kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/docker/9c13b2c56bcbd99b2cd6b66f1f8009072a6cef3c76db3819560af169514f1c2b,task=ffmpeg,pid=25112,uid=0 Mar 4 04:03:19 Andromeda kernel: Out of memory: Killed process 25112 (ffmpeg) total-vm:35154720kB, anon-rss:34703828kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:68236kB oom_score_adj:0 Dunno, just a guess based on all the errors in the log Mar 4 04:21:02 Andromeda kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth622dd44: link becomes ready Mar 4 04:21:02 Andromeda kernel: br-fb0d039ca56f: port 28(veth622dd44) entered blocking state Mar 4 04:21:02 Andromeda kernel: br-fb0d039ca56f: port 28(veth622dd44) entered forwarding state Mar 4 04:21:04 Andromeda kernel: br-fb0d039ca56f: port 28(veth622dd44) entered disabled state Mar 4 04:21:04 Andromeda kernel: veth70b83b4: renamed from eth0 Mar 4 04:21:04 Andromeda kernel: br-fb0d039ca56f: port 28(veth622dd44) entered disabled state Mar 4 04:21:04 Andromeda kernel: device veth622dd44 left promiscuous mode Mar 4 04:21:04 Andromeda kernel: br-fb0d039ca56f: port 28(veth622dd44) entered disabled state Mar 4 04:22:04 Andromeda kernel: br-fb0d039ca56f: port 28(veth1e7adde) entered blocking state Mar 4 04:22:04 Andromeda kernel: br-fb0d039ca56f: port 28(veth1e7adde) entered disabled state Mar 4 04:22:04 Andromeda kernel: device veth1e7adde entered promiscuous mode Mar 4 04:22:04 Andromeda kernel: eth0: renamed from vethb1e8c0f
-
Looks like your NVR isn't configured correctly, the ffmpeg process ran the host out of RAM You also have a lot of network errors, check your docker containers to make sure you're not sharing ports or something
-
SOLVED: Out of memory error from Fix Common Problems plugin
Michael_P replied to JudasD's topic in General Support
Do you have any other logs? The only instances in your attached diagnostics were mprime related.