ZoneMinder Forums

At one site with a lot of cameras, I was running two servers. One recording 24/7 and one doing just modect. Due to a reorganisation, I thought I could get everything running on one server - and it proved to work very well. I post this because of the scale of use is beyond the norm.

Server is an HP ML115 with 2gb ram and a quad core AMD (Bogomips total: 18k). This is a cheap and cheerful server costing about £230 (although watch for sales, HP do cashback deals very often) It has a 1tb drive for zm images and another for os which keeps images for aroudn 3 weeks. Debian has the jpg-turbo libs installed.

Cameras are all IP cameras. Mixture of Axis 205,206,207,211, Y-Cam Black, A panasonic and a couple of those $40 dealextreme cameras. Distro is debian lenny and using zm 1.24.2

Recording:

20 cameras at 1.25 fps, 640x480. Approx half recording at greyscale, the rest in colour. This was the original batch and produced a load of around 0.1 - 0.2 (it being a quad core, 4.0 is 100%)

Motion:

13 cameras at 3 fps, 640x480 colour. A single zone per monitor and set to "Best, Most sensitive" and cropped to what's needed. (On average, about 75% of the image is within the zone)

The motions were added and don't appear to have affected system load massively... ( load average: 0.21, 0.13, 0.10 )

Follows some munin graphs showing the difference on 01 from before (20 cams, just recording) and after (33 cams)

How about your i/o performance? What load do you get when you reach the max capacity and the purge filter stars working and your deleting and writing to the disks at the same time.
Are ypu using raid, fastest disk, what filesystem?

That has been always my biggest trouble when managing big setups with lots of cameras.

You can also decrees mem useage by kicking apache out the door nginX (engineX) uses about 5 mb or ram total. mod_php is very inefficient

I tested with iotop manually and it was bursting at 5mb/s write, but also showing 0KB/s. That along with the low load measures tell me it's not struggling. Wasn't expecting much extra from that since the modect is light on i/o.

Not a raid, just the supplied sata drive for boot and a normal 1tb sata drive (non-green) for the images. Running on ext2 for the tb (not worth the overhead of ext3)

And yeah, apache and mysql could both be tweaked to use even fewer resources, but generally I'm happy with the debian defaults and wanted to keep it near stock. Only real addition is the turbo libs which may one day make their way into stable as they have done with ubuntu.

would be nice to get such a low load. i only have 4 axis IP cams in modect and the load is already about 3 during the day, this being a quad core also. we plan to have about 10 cams. when i try to lower the FPS to anything below 20, though, there is a huge delay of about 10 seconds introduced into the live streams. also using 1.24.2

The fix for the stream lag with Axis cameras is to blank (no value) the fps on the monitor source tab and throttle the fps feed at the camera. Search the forums; many fixes for various cameras and browser choices.

bb99 i tried that but that just makes ZM read the cameras at 30 fps and so the system load goes up even higher

Strange that limiting the framerate in the cameras on board setup would still yield a higher fps...
http://www.zoneminder.com/forums/viewto ... +framerate

You may need to include a framerate value in the Remote Host Path: /axis-cgi/mjpg/video.cgi?fps=15&resolution=640x480 or something similar.

Thanks. i think the issue is ZM needs the cam to be reloaded for the changes to the AXIS config to be recognized. So after i changed the FPS in the AXIS config, i changed the cam in ZM to 'Monitor' and then back to 'Modect' and now ZM is getting the correct FPS...