why is zma running ? , nodect and no zones

[jperkins]

Thanks for any insight into this .

cant grasp why /usr/bin/zma is running on camera feeds that are setup as nodect and have '0' zones setup ?

total of 8 cameras h264 passthrough :
I have 8 monitors running MoCord on sub channels. they are doing all the analysis. (4CIF 20/10 FPS) ( monitors 1-8 )
have 8 more monitors running NoDect with '0' zones setup as linked to the first 8 channels. (4MP 20/10 fps) ( monitors 10-17)

And the monitors with Nodect are using more resources ??

Code: Select all

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                     
  46065 www-data  20   0 3186224   2.9g   2.8g S   7.9   6.2   0:41.60 /usr/bin/zma -m 11                          
  46067 www-data  20   0 3186224   2.9g   2.8g S   7.9   6.2   0:41.68 /usr/bin/zma -m 12                          
  46066 www-data  20   0 3186224   2.9g   2.8g R   7.3   6.2   0:39.75 /usr/bin/zma -m 10                          
  46060 www-data  20   0 3186224   2.9g   2.8g S   6.6   6.2   0:32.58 /usr/bin/zma -m 14                          
  46062 www-data  20   0 3186224   2.9g   2.8g S   6.3   6.2   0:32.58 /usr/bin/zma -m 15                          
  46059 www-data  20   0 3186224   2.9g   2.8g S   5.6   6.2   0:33.30 /usr/bin/zma -m 13                          
  45945 www-data  20   0  496456 312124 290360 S   4.6   0.6   0:24.91 /usr/bin/zma -m 2                           
  45960 www-data  20   0  497816 313776 290320 S   4.3   0.7   0:25.00 /usr/bin/zma -m 3                           
  46064 www-data  20   0 2592224   2.3g   2.2g S   4.3   5.0   0:21.45 /usr/bin/zma -m 17                          
  45920 www-data  20   0  496772 312612 290472 S   4.0   0.6   0:21.52 /usr/bin/zma -m 1                           
  46063 www-data  20   0 2592224   2.3g   2.2g S   4.0   5.0   0:20.90 /usr/bin/zma -m 16                          
  45874 www-data  20   0  497752 313808 290680 S   3.3   0.7   0:17.57 /usr/bin/zma -m 5                           
  45888 www-data  20   0  497076 312772 290324 S   3.3   0.6   0:17.82 /usr/bin/zma -m 6                           
  45860 www-data  20   0  497076 312748 290304 S   3.0   0.6   0:17.98 /usr/bin/zma -m 4                           
  45911 www-data  20   0  500752 315484 295100 S   3.0   0.7   0:15.93 /usr/bin/zma -m 8                           
  45996 www-data  20   0  502788 318872 296440 S   3.0   0.7   0:15.93 /usr/bin/zma -m 7  

monitor 9 not in use

[shortcircuit]

What happens if you unlink the detection cameras? If I set my 4mp cameras as nodect, there is a zmc and a zma process for them, but the zma process uses 0 cpu resources.

Just curious, as I am troubleshooting my own setup, what is your processor utilization on your zmc processes? My 4CIF substreams are only using about 6.0%, but the 4MP streams are running at 60.0%. I notice your zma processes are only using about 8.0% on your 4MP streams, but if I turn on motion detection on mine, it runs closer to 50.0%.

I am currently running zoneminder on a Xeon 2640 test system, I noticed a huge difference in the amount of CPU being used from the original system, which was running on an old AMD APU.

[shortcircuit]

Update, I tried linking one of the cameras like you say you have yours, and the zma process for the 4MP camera in nodect mode does start to use some cpu time, but very little.

[jperkins]

Hello. thanks for the reply. No I never unlinked them. I did consider setting the analysis FPS at 1 and assumed that would help.

Basically I havent done anything in this area since mentioning it. Using a sub channel linked to main channel on nodect has really cut down on my cpu and storage requirements, so overall it is a big win.

found this little snippet to extract the info you wanted from top

Code: Select all

               top -c -p $(pgrep -f zmc | head -20 | tr "\\n" "," | sed 's/,$//')

Here is the output for zmc:

Code: Select all

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                     
  96633 www-data  20   0 3157108   2.8g   2.8g S  44.3   6.1 201:22.10 /usr/bin/zmc -m 11                          
  96643 www-data  20   0 3154324   2.8g   2.8g R  43.3   6.1 203:48.04 /usr/bin/zmc -m 12                          
  96625 www-data  20   0 3157664   2.8g   2.8g S  43.0   6.1 201:26.53 /usr/bin/zmc -m 10                          
  96658 www-data  20   0 3155588   2.8g   2.8g S  43.0   6.1 213:15.18 /usr/bin/zmc -m 15                          
  96655 www-data  20   0 3156668   2.8g   2.8g S  41.0   6.1 202:50.74 /usr/bin/zmc -m 13                          
  96657 www-data  20   0 3155108   2.8g   2.8g R  40.3   6.1 195:58.46 /usr/bin/zmc -m 14                          
  97965 www-data  20   0 2556488   2.3g   2.2g S  27.0   4.9 152:27.17 /usr/bin/zmc -m 16                          
  97974 www-data  20   0 2552692   2.2g   2.2g S  14.3   4.9  70:51.99 /usr/bin/zmc -m 17                          
  97979 www-data  20   0  497444 317960 302840 S   5.7   0.7  27:31.20 /usr/bin/zmc -m 8                           
  96585 www-data  20   0  489600 309364 296056 S   4.7   0.6  25:06.85 /usr/bin/zmc -m 1                           
  96594 www-data  20   0  491108 310460 295472 S   4.7   0.6  23:09.55 /usr/bin/zmc -m 2                           
  96603 www-data  20   0  488352 307116 295044 S   4.3   0.6  26:06.14 /usr/bin/zmc -m 5                           
  96676 www-data  20   0  493176 313644 296616 S   4.3   0.7  24:07.48 /usr/bin/zmc -m 3                           
  96685 www-data  20   0  488372 306580 294392 S   3.3   0.6  15:53.16 /usr/bin/zmc -m 4                           
  97948 www-data  20   0  495484 316020 302700 S   3.3   0.7  15:13.90 /usr/bin/zmc -m 7                           
  96466 www-data  20   0  488920 308640 296156 S   3.0   0.6  17:22.91 /usr/bin/zmc -m 6    

and for comparison, zma:

Code: Select all

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                     
  96663 www-data  20   0 3258248   2.9g   2.8g S   6.7   6.4  31:30.20 /usr/bin/zma -m 11                          
  96664 www-data  20   0 3186224   2.9g   2.8g S   6.7   6.2  31:43.42 /usr/bin/zma -m 12                          
  96667 www-data  20   0 3258248   2.9g   2.8g S   6.7   6.4  30:49.40 /usr/bin/zma -m 15                          
  98016 www-data  20   0 3258248   2.9g   2.8g S   6.3   6.4  31:06.64 /usr/bin/zma -m 10                          
  96665 www-data  20   0 3186224   2.9g   2.8g S   6.0   6.2  30:28.07 /usr/bin/zma -m 14                          
  96666 www-data  20   0 3186224   2.9g   2.8g S   6.0   6.2  30:12.39 /usr/bin/zma -m 13                          
  96660 www-data  20   0  513096 327804 289392 S   4.7   0.7  22:26.39 /usr/bin/zma -m 2                           
  97980 www-data  20   0 2592224   2.3g   2.2g S   4.7   5.0  21:41.55 /usr/bin/zma -m 16                          
  96467 www-data  20   0  506772 322600 290528 S   4.3   0.7  21:17.23 /usr/bin/zma -m 6                           
  96686 www-data  20   0  510044 326240 290552 S   4.0   0.7  19:06.57 /usr/bin/zma -m 4                           
  97981 www-data  20   0  510972 325324 295084 S   4.0   0.7  19:02.57 /usr/bin/zma -m 8                           
  97982 www-data  20   0 2592224   2.3g   2.2g S   4.0   5.0  19:36.47 /usr/bin/zma -m 17                          
  98015 www-data  20   0  512776 328704 290548 S   4.0   0.7  20:21.63 /usr/bin/zma -m 3                           
  96662 www-data  20   0  504076 320192 290476 S   3.7   0.7  16:01.09 /usr/bin/zma -m 5                           
  98012 www-data  20   0  507380 323284 290528 S   3.3   0.7  16:32.82 /usr/bin/zma -m 1                           
  97954 www-data  20   0  515324 331736 296772 S   3.0   0.7  14:51.75 /usr/bin/zma -m 7    

zoneminder is in a kvm VM and being fed 12 CPU threads from older Xeon's

Code: Select all

jperkins@zoneminder:~$ cat /proc/cpuinfo |tail -n27 -|head
processor	: 11
vendor_id	: GenuineIntel
cpu family	: 6
model		: 44
model name	: Westmere E56xx/L56xx/X56xx (IBRS update)
stepping	: 1
microcode	: 0x1
cpu MHz		: 2933.436
cache size	: 16384 KB
physical id	: 11

[shortcircuit]

Not entirely related to your original post, but I have been trying to get a similar setup to yours running well, and have been running into some issues.

We are trying to setup a system with 16 4MP IP cameras. ZoneMinder works fine on the first few cameras, but the CPU usage on the zmc processes is so high, that it chokes after 10 or so cameras goes online.

That is what led me to your thread, thought that using the low res CIF substreams at a lower fps for detection and just direct recording the h.264 main streams should greatly reduce the CPU usage.

However, the point I can't figure out right now is why the CPU usage is so high on what should be zmc doing direct recording from the h.264 RTSP streams. As I understand the documentation, zmc is using ffmpeg libraries for the recording, and if I use ffmpeg to directly record the RSTP streams from my cameras, CPU usage is about 2% per stream. Same stream in ZoneMinder is running at 60% per stream, which means I would have to have a whole core dedicated to every camera stream.

As far as I can tell, ZoneMinder is still doing some kind of processing on the video streams, which should be unnecessary for direct recording. But I can't seem to find a way to turn it off. I attempted to use the Options under monitor configuration, but I have not had much luck finding documentation on these.

I see pretty much the same thing in the top info you sent, your zmc recording streams are still running at 40% per camera, while lower than mine, still way high for a stream that is just being recorded to disk.

[jperkins]

As far as I can tell, ZoneMinder is still doing some kind of processing on the video stream

Only thing I can think of is this setting

Monitor -> source --> Source Tab

Save JPEGs -->Analysis images only (if available)
Video Writer  -->H264 Camera Passthrough

[shortcircuit]

I put save JPEGs to disabled, and Video Writer to H264 Camera Passthrough, which I thought would do basically the same thing as ffmpeg does when pulling an RTSP stream to disk, with about 2% CPU usage for 4MP cameras. So I was very surprised when the CPU usage was so extreme.

I tried a similar setup on BlueCherry NVR software, and that one seems to do just a few percent CPU usage for recording, as expected, although it's CPU usage spikes on live views of the streams. I don't care for BlueCherry's user interface though, ZoneMinder has a much better viewing system. And although it is open source and has a free community version, BlueCherry really wants you to pay for their product. Which I would, if it was a really good product, but even with it's issues, ZoneMinder is much better.

[shortcircuit]

Just an update to what I have done on my setup since last posting to this thread, if anyone is interested.

I decided to try the 1.35 version of Zoneminder, even though it doesn't have a stable release yet, as one of Isaac Conner's posts in the development forum indicated this was an issue they are addressing in the new version.

We have had it live for about a month now, with only two issues so far - at first, memory usage would go crazy after a few hours of recording, until the server basically died, and had to be rebooted to free the memory. Assuming some kind of memory leak, but after reading some more in the 1.35 forums, I was able to find a workaround by greatly reducing the default video buffers, from 20 to 2, which seems to have taken care of the issue. As I said, the zoneminder server has been stable now for almost a month.

Other issue may not be specific to the version of zoneminder, but I have noticed that when fast forwarding recorded video, sometimes the video will freeze. Probably a totally unrelated issue.

In any case, I am happy to report that 1.35 introduced a setting on the main settings page for each camera, allowing live video processing to be disabled, massively reducing the CPU load on a machine that is just recording streams and doesn't need to be live viewing them. Our dual Xeon server is running at around 3 to 5% while recording 16 4MP streams and monitoring 16 4CIF substreams for live viewing.

Unrelated but also possibly of interest to some people, we are getting about 3.5 days of recording with the 16 4MP cameras, running at 15fps onto a 2TB drive. Looking to upgrade the storage later for more recording, but this setup is meeting our needs for now. Really looking forward to the first stable production releases of 1.35, so far, even with the minor bugs to work around, it already seems to have much more useful features than 1.34.