-
Notifications
You must be signed in to change notification settings - Fork 33
kerberosio - very high memory usage when 1024x768 resolution and delay set to 100 #28
Comments
Thanks for reporting do you see some recordings as well in the /capture dir? |
Yes there are some recordings:
|
@cedricve I can set up the ssh+ngrok service in the kerberos container so that you can remotely login with ssh into it and take a look inside. |
thank you @ChieftainY2k, are you able to reproduce as well? |
@ChieftainY2k were you experiencing, or did you ever tested, with previous Kerberos version? I understand you were using the .deb files before? |
@cedricve I was able to reproduce the problem with the following setups:
All above running with the Raspberry Pi 4 Model B Rev 1.1 (2GB) Could not test the Official KIOS SD image 2.7.2 (https://github.com/kerberos-io/kios/releases/download/v2.7.2/kios-raspberrypi3-20180714.img.gz) - my RPI4 would not even boot with this image, I don't know why (tested with two different SD cards to be sure). |
Thanks for the detailed information! RaspberryPi 4 is only supported from 2.8.0.
What happens if you test with a Raspberry Pi 3? Just curious..
Kind regards,
Verstraeten Cédric
… On 30 May 2020, at 11:27, ChieftainY2k ***@***.***> wrote:
@cedricve I was able to reproduce the problem with the following setups:
Official KIOS SD image 2.8.0 (https://github.com/kerberos-io/kios/releases/download/v2.8.0/kios-raspberrypi4-2.8.0.img.gz)
Docker image from the official kerberos docker repository (https://hub.docker.com/r/kerberos/kerberos)
My own docker image with deb package from https://github.com/kerberos-io/machinery/releases/download/v2.8.0/rpi4-machinery-kerberosio-armhf-2.8.0.deb (with corresponding libx264.so.148 and libx265.so.160)
My own docker image with deb package from https://github.com/kerberos-io/machinery/releases/download/v2.8.0/rpi3-machinery-kerberosio-armhf-2.8.0.deb (with corresponding libx264.so.148 and libx265.so.160)
My own docker image with deb package from https://github.com/kerberos-io/machinery/releases/download/v2.6.2/rpi3-machinery-kerberosio-armhf-2.6.2.deb
All above running with the Raspberry Pi 4 Model B Rev 1.1 (2GB)
Could not test the Official KIOS SD image 2.7.2 (https://github.com/kerberos-io/kios/releases/download/v2.7.2/kios-raspberrypi3-20180714.img.gz) - my RPI4 would not even boot with this image, I don't know why (tested with two different SD cards to be sure).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
also @ChieftainY2k what is the reason of setting delay to 100? Do you also experience with lower values? |
@cedricve I was just playing around with optimal parameters to detect motion in the area my camera is pointed at and then after setting delay do 100 this memory bug happened. Then I set it back to 500 everything goes back to normal after a while. |
Just tested it with following setup and was able to reproduce the memory problem:
|
Interesting it might be that the os is not able to free up the resources. Can you experiment (incremental) which params are causing this issue. Could be that it is resolved once beyond 250 (wild guess). You said that with 500 it is ok? But probably this takes to long for you to detect motion? I will look into the source code to find the root cause. Let me know what you find as well 👌 Thanks for the hard work @ChieftainY2k Let me know |
This Jogged my brain of the issue I had with memory overloading.
|
We are working on a complete rewrite of the open source version. When using h264 cameras, you will be able to record at almost no CPU (<1%). Already implemented through our enterprise offering but not yet released in the open source repo, |
Memory usage is VERY high (eventually bringing my raspberry pi4 to a halt) when using specific configuration for raspberry onboard camera.
Steps to reproduce:
docker run --name camera -p 80:80 -p 8889:8889 -d -v /dev/vcsm:/dev/vcsm -v /dev/vchiq:/dev/vchiq --privileged kerberos/kerberos
Result:
Within several minutes memory usage soars over 1.5GB, eventually raspberry pi runs out of memory, swap space kicks in and everything is halted.
Expected result:
Memory usage is expected to be reasonable :-)
Rig specs:
The text was updated successfully, but these errors were encountered: