[Support]: Certain actions cause CPU spike in recordings, and cache fills up #11211
Replies: 2 comments 4 replies
-
|
I just upgraded to 0.13.2 and still observe the same behavior (everything else is the same) |
Beta Was this translation helpful? Give feedback.
-
|
Nice job getting that running so well on the RPi 3--I didn't think it could even run with a 1 GB RAM machine. I use an RPi5/4GB, albeit with local RPi cameras, and it's a hog on CPU and memory. My /tmp/cache sits around 1.8 MiB, though I did allocate 1 GB to it via Docker. With limited RAM, you might not have the option, but might help to increase /tmp/cache: https://docs.frigate.video/frigate/installation#docker Shooting in the dark, does And, just throwing it out there, your disk isn't full, is it? Tangent(??) - how did you get the 0.13.x release working on your 32-bit OS? Frigate dropped support in the 0.13.0 release: https://github.com/blakeblackshear/frigate/releases/tag/v0.13.0
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply. The disk isn't full and my shm usage is very low (~4MB compared to the 64MB limit). Update: I noticed the "dphys-swapfile" service my RPI was failing, and since I fixed that (and set vm.swappiness down from 60 to 1) , I'm noticing much better performance all-around. The web pages load immediately, and the /tmp/cache is staying around 30MB (for 5x 1080p 30fps cameras).
I cloned the repo on my workstation, I checked out 0.13.2 tag, I manually edited the main Dockerfile and main install_deps.sh scripts to incorporate some of the things they used to have in 0.12.1 to support arm32. I also edited the Dockerfile to use apt-get to install
|
Beta Was this translation helpful? Give feedback.
-
|
That's impressive - both the swapfile configuration and building the 0.13 file to work on 32-bit again. 👏 And now I'm going down a rabbit hole reading about swappiness. On that topic - is lowering it to 1 better for the Frigate NVR-focused system use case ? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not an expert sysadmin. so maybe someone else can offer a better perspective. But seems to me that in this scenario where:
it seems better to set the swappiness to a lower value, to give up file-loading optimization in favor of keeping heap off of a slow disk |
Beta Was this translation helpful? Give feedback.
-
|
I've created a Pull Request to restore Arm32 support. We will see if the maintainers agree to support the approach long-term -- it should solve some of the complications they've run into. If not, then at least someone else might benefit from referring to the PR to do a local build |
Beta Was this translation helpful? Give feedback.
-
Describe the problem you are having
I've got 3 cameras, each with two H264 streams: 1080p (30fps) for recording, and 352x240 (2fps) for detection. Hardware decoding is working for all streams using h264_v4l2m2m. There's no camera-specific ffmpeg config. My CPU usage is generally low (htop reports a load average of 2.6, when this RPI has 4 cores). I've got a USB Coral that the logs suggest is working correctly.
I've got my RPI configured to use 128MB GPU memory, and my /tmp/cache is 128 MB. (It's an RPI 3B+ with 1GB RAM and I'm running 0.12.1 on 32-bit ARM Raspbian Buster -- I got it working by telling docker-compose to build the Dockerfile below).
Most of the time, the /tmp/cache is hovering at under 30MB usage. But sometimes I will do one of the following actions, and notice that suddenly the /tmp/cache fills up. According to htop, it looks like the ffmpeg processes that record to /tmp/cache temporarily spike the CPU.
docker exec -it frigate bash)docker logs frigate -f -n100)Cleaning out /tmp/cache isn't enough to get it caught up. I need to actually restart the container for it to get it hovering under 30MB cache again.
Has anyone encountered this spike in CPU while recording, that triggers an irrecoverable filling of the recording cache?
Version
0.12.1
Frigate config file
Relevant log output
FFprobe output from your camera
Frigate stats
Operating system
Debian
Install method
Docker Compose
Coral version
USB
Network connection
Wired
Camera make and model
2 hikvision and 1 amcrest
Any other information that may be helpful
No response
Beta Was this translation helpful? Give feedback.
All reactions