Take the frame rate down to 5 or so. Make your pixel size smaller.
1900X1200 is too big. Go 1/2 D1 maybe or 1/4 D1.
Read this:
slow down capture, speed up analysis or increase ring buffer
Math for Memory: Making sure you have enough memory to handle your cameras
One of the most common issues for erratic ZoneMinder behavior is you don’t have enough memory to handle all your cameras. Many users often configure multiple HD cameras at full resolution and 15FPS or more and then face various issues about processes failing, blank screens and other completely erratic behavior. The core reason for all of this is you either don’t have enough memory or horsepower to handle all your cameras. The solution often is to reduce FPS, reduce cameras or bump up your server capabilities.
Here are some guidelines with examples on how you can figure out how much memory you need. With respect to CPU, you should benchmark your server using standard unix tools like top, iotop and others to make sure your CPU load is manageable. ZoneMinder also shows average load on the top right corner of the Web Console for easy access.
In
general a good estimate of memory required would be:
Min Memory = 1.2 * ((image-width*image-height*image buffer size*target color space*number
Or, around 900MB of memory.
So if you have 2GB of memory, you should be all set. Right?
Not, really:
- This is just the base memory required to capture the streams. Remember ZM is always capturing streams irrespective of whether you are actually recording or not - to make sure its image ring buffer is there with pre images when an alarm kicks in.
- You also need to account for other processes not related to ZM running in your box
- You also need to account for other ZM processes - for example, I noticed the audit daemon takes up a good amount of memory when it runs, DB updates also take up memory
So a good rule of thumb is to make sure you have twice the memory as the calculation above (and if you are using the ZM server for other purposes, please factor in those memory requirements as well)
Also remember by default ZM only uses 50% of your available memory unless you change it
As it turns out, ZM uses mapped memory and by default, 50% of your physical memory is what this will grow to. When you reach that limit , ZM breaks down with various errors.
(
Note: Mapped memory is applicable when you install ZoneMinder with mapped memory support, which is the default mode. If you have specifically disabled mapped memory then please see the next FAQ enty on how to increase shared memory)
A good way to know how much memory is allocated to ZM for its operation is to do a df -h
A sample output on Ubuntu:
pp@camerapc:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 226G 96G 119G 45% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 1.8G 4.0K 1.8G 1% /dev
tmpfs 371M 816K 370M 1% /run
none 5.0M 0 5.0M 0% /run/lock
tmpfs 2.6G 923M 1.7G 36% /run/shm
none 100M 0 100M 0% /run/user
The key item here is tmpfs –> the example above shows we have allocated 1.7G of mapped memory space of which 36% is used which is a healthy number. If you are seeing this to go beyond 70% you should probaby increase mapped memory
If you want to increase this limit to 70% of your memory, add the following to /etc/fstab tmpfs /run/shm tmpfs defaults,noexec,nosuid,size=70% 0 0
What does a ‘Can’t shmget: Invalid argument’ error in my logs mean? (and my camera does not display at higher resolutions)
(
Note: This is applicable for systems that have mapped memory disabled in ZoneMinder. By default, Mapped memory is enabled and unless you have disabled it manually, please refer to the “Math for Memory” question above and how to increase mapped memory limits)
This error is discussed in the README in the following excerpt:- ‘’...this is caused by an attempt to allocate an amount of shared memory greater than your system can handle. The size it requests is based on the following formula, ring buffer size x image width x image height x 3 (for 24 bit images) + a bit of overhead.
So, for example:
384x288 capture resolution, that makes: 110 592 pixels
in 24 bit color that's x24 = 2 654 208 bits per frame
by 80 frames ring buffer x80 = 212 336 640 bits per camera
by 4 cameras x4 = 849 346 560 bits.
Plus 10% overhead = 934 281 216 bits
That's 116 785 152 bytes, and
= 114 048 kB, respectively 111.38 MB.
If my shared memory is set to 134 217 728, which is exactly 128MB,
that means I shouldn't have any problem.
(Note that 1 byte = 8 bits and 1kbyte = 1024bytes, 1MB = 1024 kB)
If for instance you were using 24bit 640x480 then this would come to about 92Mb if you are using the default buffer size of 100. If this is too large then you can either reduce the image or buffer sizes or increase the maximum amount of shared memory available. If you are using RedHat then you can get details on how to change these settings
here
You should be able to use a similar procedure with other distributions to modify the shared memory pool without kernel recompilations though in some cases this may be necessary. Note, this error also sometimes occurs if you have an old shared memory segment lying around from a previous run that is too small. Use the ipcs and ipcrm system commands to check and remove it if necessary.’”
You can often find out how many 4KB shared memory pages are available by typing the following :-
# cat /proc/sys/kernel/shmall
2097152
In recent kernels the shmall is set to 2097152 memory pages multiplied by 4096 bytes per page for a total of 8 GB of shared memory available. You only need to increase the shmall value if you have a computer with more than 8GB of memory and wish to use more of it for shared memory usage, such as large databases.
The most shared memory bytes you can allocate in one go :-
# cat /proc/sys/kernel/shmmax
33554432
In recent kernels the shmmax is set to 33554432 bytes for only 32 MB of maximum shared memory allocatable at a time, hardly enough for ZoneMinder to go above 320 x 240 x 24-bit resolution at 40 frames in the buffer if it is using the /dev/shm shared memory device, so this value needs to be increased. If you are using ZoneMinder with the memory mapped (mmap) compile time option then this doesn’t affect you.
To change the value to 128 MB temporarily during this kernel execution type (for example) :-
echo 536870912 >/proc/sys/kernel/shmmax
Be sure to restart ZoneMinder after this.
However be aware that sometimes you will only need to change the shmmax value as shmall is often large enough. Also changing these values in this way is only effective until your machine is rebooted.
To change them permanently you will need to edit /etc/sysctl.conf and add the following lines (for example) :- kernel.shmmax = 536870912
Or if your distribution has the /etc/sysctl.d/ folder you can create a file in this folder without modifying the /etc/sysctl.d so you won’t lose the changes during distro upgrades :- `echo kernel.shmmax = 536870912 >/etc/sysctl.d/60-kernel-shm.conf`
To load these settings in the sysctl.conf file type: sysctl -p
To check your shared memory settings type: ipcs -l
Note that with Megapixel cameras like the Axis 207mw becoming cheaper and more attractive, the above memory settings are not adequate. To get Zoneminder working with a full 1280x1024 resolution camera in full color, increase 134217728 (128 MB) to, for example, 268435456 (256 MB) and multiple this value by each camera.
These changes will now also be set the next time your machine is restarted.
Versions 1.24.x of ZoneMinder also allows you to use an alternate method of shared memory allocation,
Mmap mapped memory . This requires less configuration and can be simpler to use. Mapped memory allows you to use a special type of file as the placeholder for your memory and this file is ‘mapped’ into memory space for easy and fast access.
To enable mapped memory in ZoneMinder you need add add the –enable–mmap=yes switch to your configure line. By default mapped memory files are created in /dev/shm which on most distributions is a dedicated pseudo-partition containing memory formatted as a filesystem. If your system uses a different path then this can be changed in ZoneMinder in Options->paths->PATH_MAP. It uses a filesystem type called
tmpfs. If you type df -h you should see this area and the size of memory it currently allows. To increase size for tmpfs you need to edit /etc/default/tmpfs. Search for: SHM_SIZE=128M and change to something like SHM_SIZE=1G then reboot the system. You could possibly need to change RUN_SIZE, too.
It is important that you do not use a disk based filesystem for your memory mapped files as this will cause memory access to be extremely slow. ZoneMinder creates files called .zm.mmap.<monitor id> in the mapped memory filesystem.
Mapped memory is subject to the same limitations in terms of total memory as using more traditional shared memory but does not require any configuration per allocation or chunk. In future versions of ZoneMinder this will be the default shared memory storage method.
Another good article about shared memory settings can be found
here .
The essential difference was that the kernel.shmall setting is NOT in a direct memory setting in KB but in pages of memory. it is Max Pages of memory
For example: If you want to allocate a maximum memory setting to 8GB you have to convert it to the number of pages (or segments). with a page size of 4096. kernel.shmall = 8000x1024x1024/4096 kernel.shmall = 2097152 NOT 8388608000 as would be suggested in the RedHat article linked above.
shmmax is the max amount to allocate in one request - this is is an actual memory size (as opposed to pages) set to 4GB kernel.shmmax = 4294967296
The /etc/sysctl.conf would have these lines
kernel.shmall = 2097152
kernel.shmmax = 4294967296</pre>
As above, reload your sysctl.conf with sysctl -p and check that the settings are correct with ipcs -l.
I have enabled motion detection but it is not always being triggered when things happen in the camera view
ZoneMinder uses zones to examine images for motion detection. When you create the initial zones you can choose from a number of preset values for sensitivity etc. Whilst these are usually a good starting point they are not always suitable for all situations and you will probably need to tweak the values for your specific circumstances. The meanings of the various settings are described in the documentation (
here) however if you believe you have sensible settings configured then there are two diagnostic approaches you can use.
Event Statistics
The first technique is to use event statistics. Firstly you should ensure they are switched on in Options->Logging->RECORD_EVENT_STATS. This will then cause the raw motion detection statistics for any subsequently generated events to be written to the DB. These can then be accessed by first clicking on the Frames or Alarm Frames values of the event from any event list view in the web gui. Then click on the score value to see the actual values that caused the event. Alternatively the stats can be accessed by clicking on the ‘Stats’ link when viewing any individual frame. The values displayed there correspond with the values that are used in the zone configuration and give you an idea of what ‘real world’ values are being generated.
Note that if you are investigating why events ‘do not’ happen then these will not be saved and so won’t be accessible. The best thing to do in that circumstance is to make your zone more sensitive so that it captures all events (perhap even ones you don’t want) so you can get an idea of what values are being generated and then start to adjust back to less sensitive settings if necessary. You should make sure you test your settings under a variety of lighting conditions (e.g. day and night, sunny or dull) to get the best feel for that works and what doesn’t.
Using statistics will slow your system down to a small degree and use a little extra disk space in the DB so once you are happy you can switch them off again. However it is perfectly feasible to keep them permanently on if your system is able to cope which will allow you to review your setting periodically.
Diagnostic Images
The second approach is to use diagnostic images which are saved copies of the intermediate images that ZM uses when determining motion detection. These are switched on and off using Options->Logging->RECORD_DIAG_IMAGES.
There are two kinds of diagnostic images which are and are written (and continuously overwritten) to the top level monitor event directory. If an event occurs then the files are additionally copied to the event directory and renamed with the appropriate frame number as a prefix.
The first set are produced by the monitor on the image as a whole. The diag-r.jpg image is the current reference image against which all individual frames are compared and the diag-d.jpg image is the delta image highlighting the difference between the reference image and the last analysed image. In this images identical pixels will be black and the more different a pixel is the whiter it will be. Viewing this image and determining the colour of the pixels is a good way of getting a feel for the pixel differences you might expect (often more than you think).
The second set of diag images are labelled as diag-<zoneid>-<stage>.jpg where zoneid is the id of the zone in question (Smile) and the stage is where in the alarm check process the image is generated from. So if you have several zones you can expect to see multiple files. Also these files are only interested in what is happening in their zone only and will ignore anything else outside of the zone. The stages that each number represents are as follows,
# Alarmed Pixels - This image shows all pixels in the zone that are considered to be alarmed as white pixels and all other pixels as black. # Filtered Pixels - This is as stage one except that all pixels removed by the filters are now black. The white pixels represent the pixels that are candidates to generate an event. # Raw Blobs - This image contains all alarmed pixels from stage 2 but aggrageted into blobs. Each blob will have a different greyscale value (between 1 and 254) so they can be difficult to spot with the naked eye but using a colour picker or photoshop will make it easier to see what blob is what. # Filtered Blobs - This image is as stage 3 but under (or over) sized blobs have been removed. This is the final step before determining if an event has occurred, just prior to the number of blobs being counted. Thus this image forms the basis for determining whether an event is generated and outlining on alarmed images is done from the blobs in this image.
Using the above images you should be able to tell at all stages what ZM is doing to determine if an event should happen or not. They are useful diagnostic tools but as is mentioned elsewhere they will massively slow your system down and take up a great deal more space. You should never leave ZM running for any length of time with diagnostic images on.
Why can’t ZoneMinder capture images (either at all or just particularly fast) when I can see my camera just fine in xawtv or similar?
With capture cards ZoneMinder will pull images as fast as it possibly can unless limited by configuration. ZoneMinder (and any similar application) uses the frame grabber interface to copy frames from video memory into user memory. This takes some time, plus if you have several inputs sharing one capture chip it has to switch between inputs between captures which further slows things down.
On average a card that can capture at 25fps per chip PAL for one input will do maybe 6-10fps for two, 1-4fps for three and 1-2 for four. For a 30fps NTSC chip the figures will be correspondingly higher. However sometimes it is necessary to slow down capture even further as after an input switch it may take a short while for the new image to settle before it can be captured without corruption.
When using xawtv etc to view the stream you are not looking at an image captured using the frame grabber but the card’s video memory mapped onto your screen. This requires no capture or processing unless you do an explicit capture via the J or ctrl-J keys for instance. Some cards or drivers do not support the frame grabber interface at all so may not work with ZoneMinder even though you can view the stream in xawtv. If you can grab a still using the grab functionality of xawtv then in general your card will work with ZoneMinder.
Why can’t I see streamed images when I can see stills in the Zone window etc?
This issue is normally down to one of two causes
- You are using Internet Explorer and are trying to view multi-part jpeg streams. IE does not support these streams directly, unlike most other browsers. You will need to install Cambozola or another multi-part jpeg aware pluging to view them. To do this you will need to obtain the applet from the Downloads page and install the cambozola.jar file in the same directly as the ZoneMinder php files. Then find the ZoneMinder Options->Images page and enable ZM_OPT_CAMBOZOLA and enter the web path to the .jar file in ZM_PATH_CAMBOZOLA. This will ordinarily just be cambozola.jar. Provided (Options / B/W tabs) WEB_H_CAN_STREAM is set to auto and WEB_H_STREAM_METHOD is set to jpeg then Cambozola should be loaded next time you try and view a stream.
‘’‘NOTE’‘’: If you find that the Cambozola applet loads in IE but the applet just displays the version # of Cambozola and the author’s name (as opposed to seeing the streaming images), you may need to chmod (‘’-rwxrwxr-x’‘) your (‘’usr/share/zoneminder/’‘) cambozola.jar:
sudo chmod 775 cambozola.jar
Once I did this, images started to stream for me.
- The other common cause for being unable to view streams is that you have installed the ZoneMinder cgi binaries (zms and nph-zms) in a different directory than your web server is expecting. Make sure that the –with-cgidir option you use to the ZoneMinder configure script is the same as the CGI directory configure for your web server. If you are using Apache, which is the most common one, then in your httpd.conf file there should be a line like ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" where the last directory in the quotes is the one you have specified. If not then change one or the other to match. Be warned that configuring apache can be complex so changing the one passed to the ZoneMinder configure (and then rebuilding and reinstalling) is recommended in the first instance. If you change the apache config you will need to restart apache for the changes to take effect. If you still cannot see stream reliably then try changing Options->Paths->ZM_PATH_ZMS to just use zms if nph-zms is specified, or vice versa. Also check in your apache error logs.
I have several monitors configured but when I load the Montage view in FireFox why can I only see two? or, Why don’t all my cameras display when I use the Montage view in FireFox?
By default FireFox only supports a small number of simultaneous connections. Using the montage view usually requires one persistent connection for each camera plus intermittent connections for other information such as statuses.
You will need to increase the number of allowed connections to use the montage view with more than a small number of cameras. Certain FireFox extensions such as FasterFox may also help to achieve the same result.
To resolve this situation, follow the instructions below:
Enter about:config in the address bar
scroll down to browser.cache.check_doc_frequency 3 change the 3 to a 1
browser.cache.disk.enable True -> False
network.http.max-connections-per-server -> put a value of 100
network.http.max-persistent-connections-per-proxy -> 100 again
network.http.max-persistent-connections-per-server -> 100 again
Why is ZoneMinder using so much CPU?
The various elements of ZoneMinder can be involved in some pretty intensive activity, especially while analysing images for motion. However generally this should not overwhelm your machine unless it is very old or underpowered.
There are a number of specific reasons why processor loads can be high either by design or by accident. To figure out exactly what is causing it in your circumstances requires a bit of experimentation.
The main causes are.
- Using a video palette other than greyscale or RGB24. This can cause a relatively minor performace hit, though still significant. Although some cameras and cards require using planar palettes ZM currently doesn’t support this format internally and each frame is converted to an RGB representation prior to processing. Unless you have compelling reasons for using YUV or reduced RGB type palettes such as hitting USB transfer limits I would experiment to see if RGB24 or greyscale is quicker. Put your monitors into ‘Monitor’ mode so that only the capture daemons are running and monitor the process load of these (the ‘zmc’ processes) using top. Try it with various palettes to see if it makes a difference.
- Big image sizes. A image of 640x480 requires at least four times the processing of a 320x240 image. Experiment with different sizes to see what effect it may have. Sometimes a large image is just two interlaced smaller frames so has no real benefit anyway. This is especially true for analog cameras/cards as image height over 320 (NTSC) or 352 PAL) are invariably interlaced.
- Capture frame rates. Unless there’s a compelling reason in your case there is often little benefit in running cameras at 25fps when 5-10fps would often get you results just as good. Try changing your monitor settings to limit your cameras to lower frame rates. You can still configure ZM to ignore these limits and capture as fast as possible
- Run function. Obviously running in Record or Mocord modes or in Modect with lots of events generates a lot of DB and file activity and so CPU and load will increase.
- Basic default detection zones. By default when a camera is added one detection zone is added which covers the whole image with a default set of parameters. If your camera covers a view in which various regions are unlikely to generate a valid alarm (ie the sky) then I would experiment with reducing the zone sizes or adding inactive zones to blank out areas you don’t want to monitor. Additionally the actual settings of the zone themselves may not be optimal. When doing motion detection the number of changed pixels above a threshold is examined, then this is filter, then contiguous regions are calculated to see if an alarm is generated. If any maximum or minimum threshold is exceeded according to your zone settings at any time the calculation stops. If your settings always result in the calculations going through to the last stage before being failed then additional CPU time is used unnecessarily. Make sure your maximum and minimumzone thresholds are set to sensible values and experiment by switching RECORD_EVENT_STATS on and seeing what the actual values of alarmed pixels etc are during sample events.
- Optimise your settings. After you’ve got some settings you’re happy with then switching off RECORD_EVENT_STATS will prevent the statistics being written to the database which saves some time. Other settings which might make a difference are ZM_FAST_RGB_DIFFS, ZM_OPT_FRAME_SERVER and the JPEG_xxx_QUALITY ones.
- when motion is detected.
I’m sure there are other things which might make a difference such as what else you have running on the box and memory sizes (make sure there’s no swapping going on). Also speed of disk etc will make some difference during event capture and also if you are watching the whole time then you may have a bunch of zms processes running also.
I think the biggest factors are image size, colour depth and capture rate. Having said that I also don’t always know why you get certains results from ‘top’. For instance if I have a ‘zma’ daemon running for a monitor that is capturing an image. I’ve commented out the actual analysis so all it’s doing is blending the image with the previous one. In colour mode this takes ~11 milliseconds per frame on my system and the camera is capturing at ~10fps. Using ‘top’ this reports the process as using ~5% of CPU and permanently in R(un) state. Changing to greyscale mode the blending takes ~4msec (as you would expect as this is roughly a third of 11) but top reports the process as now with 0% CPU and permanently in S(leep) state. So an actual CPU resource usage change of a factor of 3 causes huge differences in reported CPU usage. I have yet to get to the bottom of this but I suspect it’s to do with scheduling somewhere along the line and that maybe the greyscale processing will fit into one scheduling time slice whereas the colour one won’t but I have no evidence of this yet!
Why is the timeline view all messed up?
The timeline view is a new view allowing you to see a graph of alarm activity over time and to quickly scan and home in on events of interest. However this feature is highly complex and still in beta. It is based extensively on HTML div tags, sometimes lots of them. Whilst FireFox is able to render this view successfully other browsers, particular Internet Explorer do not seem able to cope and so present a messed up view, either always or when there are a lot of events. Using the timeline view is only recommended when using FireFox, however even then there may be issues.
This function has from time to time been corrupted in the SVN release or in the stable releases, try and reinstall from a fresh download.
How much Hard Disk Space / Bandwidth do I need for ZM?
Please see
this excel sheet or
this online excel sheet (both are user contributed excel sheets)
Or go to
this link for the Axis bandwidth calculator. Although this is aimed at Axis cameras it still produces valid results for any kind of IP camera.
As a quick guide I have 4 cameras at 320x240 storing 1 fps except during alarm events. After 1 week 60GB of space in the volume where the events are stored (/var/www/html/zm) has been used.
When I try and run ZoneMinder I get lots of audit permission errors in the logs and it won’t start
Many Linux distributions nowadays are built with security in mind. One of the latest methods of achieving this is via SELinux (Secure Linux) which controls who is able to run what in a more precise way then traditional accounting and file based permissions (
link). If you are seeing entries in your system log like:
Jun 11 20:44:02 kernel: audit(1150033442.443:226): avc: denied { read } for pid=5068 comm=”uptime” name=”utmp” dev=dm-0 ino=16908345 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u
bject_r:initrc_var_run_t tclass=file
then it is likely that your system has SELinux enabled and it is preventing ZoneMinder from performaing certain activities. You then have two choices. You can either tune SELinux to permit the required operations or you can disable SELinux entirely which will permit ZoneMinder to run unhindered. Disabling SELinux is usually performed by editing its configuration file (e.g., /etc/selinux/config) and then rebooting. However if you run a public server you should read up on the risks associated with disabled Secure Linux before disabling it.
Note that SELinux may cause errors other than those listed above. If you are in any doubt then it can be worth disabling SELinux experimentally to see if it fixes your problem before trying other solutions.
How do I enable ZoneMinder’s security?
In the console, click on Options. Check the box next to “ZM_OPT_USE_AUTH”. You will immediately be asked to login. The default username is ‘admin’ and the password is ‘admin’.
To Manage Users: In main console, go to Options->Users.
You may also consider to use the web server security, for example, htaccess files under Apache scope; You may even use this as an additional/redundant security on top of Zoneminders built-in security features;
Why does ZM stop recording once I have 32000 events for my monitor?
Storing more than 32k files in a single folder is a limitation of some filesystems. To avoid this, enable USE_DEEP_STORAGE under Options.
USE_DEEP_STORAGE is now the default for new ZoneMinder systems so this limitation should only apply to users upgrading from a previous version of ZoneMinder.
Versions of ZM from 1.23.0 onwards allow you to have a deeper filesystem with fewer files per individual directory. As well as not being susceptible to the 32k limit, this is also somewhat faster.
If you have upgraded from a previous version of ZoneMinder and this option is not already enabled, it is very important to follow the steps below to enable it on an existing system. Failure to properly follow these steps
WILL RESULT IN LOSS OF YOUR DATA!
# Stop ZoneMinder
# Backup your event data and the dB if you have the available storage
# Enable USE_DEEP_STORAGE under Options.
# From the command line, run "sudo zmupdate.pl --migrate-events"
# Monitor the output for any events that fail to convert.
# After the conversion completes, you can restart ZoneMinder
Note that you can re-run the migrate-events command if any error messages scroll off the screen.
You can read about the lack of a limit in the number of sub-directories in the ext4 filesystem at:
this link and see what tools may assist in your use of this filesystem
here If you search for ext3 or reiserfs on the forums you will find various threads on this issue with guidance on how to convert.
