Hi all, I've faced the same problem and would like to share my findings. But first of all, many thanks to the ZM developers and contributors for such a great development! Although it cost me couple of weeks to get more familiar with the product and to build a more or less useful setup, I think the ZM is actually the best CCTV solution on the free software market. Especially the version 1.35 with the option to disable video decoding! It just a killer feature for me, which allows to implement a hi-res CCTV system with very limited hardware resources.
My last setup, where the problem exists is follow:
Code: Select all
Server:
i3-4330T with 16GB RAM
OS Proxmox
VM with 2 cores and 8GB RAM limit
Ubuntu 20.04.2 LTS (Focal Fossa)
Zoneminder v1.35.27
Storage: WD Purple WD20PURZ thru NFS (served by Proxmox)
ZoneMinder settings:
Camera 1: Hikvision DS-2CD2142FWD
Stream 1 - "Monitor-1"
Mode: RECORD, no analysis, no decoding, camera passthrough
Source: FFMPEG TCP H.264 2688x1520x32@20fps, I-Frames 20, ~800kB/s
Linked with Monitor-3
Buffers:
Image Buffer Size 21 (>1 sec)
Maximum Image Buffer Size 0
Warmup Frames 0
Pre Event Image Count 20 (1 sec)
Post Event Image Count 100 (5 sec)
Stream Replay Image Buffer 0
Alarm Frame Count 1
Stream 2 - "Monitor-3"
Mode: MODECT, frames+analysis, video writer disabled
Source: FFMPEG TCP MJPEG 640x360x32@20fps ~300kB/s
Buffers:
Image Buffer Size 100 (5 sec)
Maximum Image Buffer Size 0
Warmup Frames 0
Pre Event Image Count 20 (1 sec)
Post Event Image Count 100 (5 sec)
Stream Replay Image Buffer 0
Alarm Frame Count 3
Camera 2: HiWatch IPC-B542
Stream 1 - "Monitor-4"
Mode: RECORD, no analysis, no decoding, camera passthrough
Source: FFMPEG TCP H.264 2688x1520x32@25fps, I-Frames 20, ~900kB/s
Linked with Monitor-7
Buffers:
Image Buffer Size 26 (>1 sec)
Maximum Image Buffer Size 0
Warmup Frames 0
Pre Event Image Count 25 (1 sec)
Post Event Image Count 125 (5 sec)
Stream Replay Image Buffer 0
Alarm Frame Count 1
Stream 2 - "Monitor-7"
Mode: MODECT, frames+analysis, video writer disabled
Source: FFMPEG TCP MJPEG 640x360x32@20fps ~700kB/s
Buffers:
Image Buffer Size 100 (5 sec)
Maximum Image Buffer Size 0
Warmup Frames 0
Pre Event Image Count 20 (1 sec)
Post Event Image Count 100 (5 sec)
Stream Replay Image Buffer 0
Alarm Frame Count 3
During testing of the setup, I've got a lot of error messages like
You have set the max video packets in the queue to 50. The queue is full. Either Analysis is not keeping up or your camera's keyframe interval is larger than this setting. We are dropping packets.
It was little bit confusing, because only MJPEG sources are decoded and analysed, and CPU utilisation is nor really high all the time. Then I've noticed, that sometimes the memory consumption is quite high. For better analysis I've installed a Zabbix agent and collected some metrics. The most interesting are the memory usage, CPU usage and memory consumption by the ZMC processes. This is how last 24h looks like:
- Zabbix_ZM_day.png (215.67 KiB) Viewed 28683 times
It is quite an obvious here, that the ZMC process of the Monitor-3 (light-blue line) and of the Monitor-7 (light-green line), where motion scan is activated, are growing till end of memory and then been restarted. Depending on amount of alarms in a period, the cycle can be shorter or longer. For example, in the night there are a lot of alarms because of spider webs in IR lights, so the cycle is quite a short. In the day there are not much movements in the camera view and the cycle is longer. Btw, the shared memory (/dev/shm) utilization stays all the time around 26%.
Then I've tried to take a look deeply in the ZMC processes. So I've catched a moment, when a ZMC process just jumped from about 1.8Gb to 3.1Gb in memory. This is the period between 13:38 and 13:41, which has 2 alarms (light-blue line):
- Zabbix_ZMC.png (48.57 KiB) Viewed 28683 times
Using the command "pmap -XX <id>" I've collected detailed process memory information at the beginning and at the end of the period. The report is saved as an
OpenOffice table. The interesting thing here is that the process constantly allocates blocks of memory each around 64kB and amount of such blocks just grows with the time. The sum of sizes of the blocks is almost the same as the process size by itself. So it really looks like as a memory leak. All details can be found in the table.
Unfortunately I have no experience with unix-based development at all and just a little with administration. So it can be easly, that my assumption is wrong. Anyway I'll be glad to assist with the problem as much as I can.