ZoneMinder Forums

I have a P 2.4 ghz IBM x205 server, with 512 MB RAM and 160 GB ATA-100 hard disk, Fedora 2.

I am running zoneminder 1.19.5 (upgraded from 1.19.4) and 2 Axis network cameras, 210 and 206W at 640x480@ 5 fps on modect function. System load is around 0.5 when there is no movement, but when both cams start to record, load jumps to 1.5 and near 2. There is no swapping going on.

The interesting fact is, that during alarm & recording each zma process uses about 30 % cpu or more, though when alarm is off analyzing takes a lot less cpu power. Zmf doesn't take much anything, and zmc behaves well also.. And i'm not using analysis images or diagnostic images settings..

ZM_OPT_FRAME_SERVER=1
ZM_CREATE_ANALYSIS_IMAGES=0
ZM_RECORD_DIAG_IMAGES=0
ZM_RECORD_EVENT_STATS=0

Btw, if I put the cameras to Record mode, the load jumps to heaven just as fast, and again zma processesses consume most of the CPU time. Is that normal? Seems strange, because zmf should do the disk-writing?

With that kind of system load, i can't add a third or fourth camera (for example Axis 2100 or 210), because the system response time becomes very high and processes just start queueing up..

My question is, is the machine really too slow for more cameras or is it possible to optimize my settings or zoneminder itself somehow? Decreasing the capture resolution or fps isn't really an option

For example, maybe I could use 320x240 stream to detect motion and trigger alarms and then save 640x480 stream.. The cameras are able to give out several streams at same time. Or is it possible to optimize something in zm code or settings?

Is anyone else using several cameras at 640x480 @ 5 fps, what kind of hardware do you have?

Please give some optimizing or hardware hints, thank you all in advance

In record mode all that will be happening is that the captured images will be re-encoded to JPEG and written to disk. If you are using zmf check your socket buffer size as it's possible that images are not actually being sent successfully to zmf (check /var/log/messages for errors to this effect). If the frames are being sent then it's likely that the only thing happening in record mode is the compression to JPEG. You might try fiddling with the compression ratio to see if this helps. Disk writing, while slow, should not consume too much CPU.

The actual alarm analysis goes through several phases

1) Check all non-inactive pixels and see which ones exceed the thresholds

If none do then this is all that is done and process terminates

2) Filter the pixels to remove isolated ones, check limits
3) Coagulate alarmed pixels into blobs, check limits

These two are little more intensive. However the ALARM_CHECK_METHOD allows you to control whether to bother with (2) and (3) or just go on (1). This may be a possible optimisation that will help you.

I'll have a think about what else might help.

Phil,

zoneminder wrote: using zmf check your socket buffer size as it's possible that images are not actually being sent successfully to zmf (check /var/log/messages for errors to this effect). If the frames are being sent
<-->
The actual alarm analysis goes through several phases
<-->
These two are little more intensive. However the ALARM_CHECK_METHOD allows you to control whether to bother with (2) and (3) or just go on (1). This may be a possible optimisation that will help you.

I'll have a think about what else might help.

Phil,

Thank you for your reply.

You were right about zmf problem, zmf keeps saying

Oct 8 22:47:17 localhost zmf-m6[27662]: ERR [Incomplete read of frame image data, 16112 bytes only]
Oct 8 22:47:17 localhost zma-m6[27667]: ERR [Incomplete frame write: 16128 of 32438 bytes written]

, i think there could be the reason performance loss. So, I added

net.core.rmem_default = 87380
net.core.wmem_default = 65535
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304

to kernel configuration and 4194304 to ZM_FRAME_SOCKET_SIZE to sysctl config, and the same error just keeps coming every time there is an alarm.. I tried smaller values too, didn't help. What else could be wrong with zmf? Could there be any more kernel tunables? Or should i just disable zmf?
I'm running kernel 2.6.8-1.521.

Thank you for quick and constructive help, I'll try out your other ideas too.. If you come up with anything else, please let me know