While adding camesras and overall working with ZM, i've noticed signifficant slowdown of the access to the ZM interafce. As more cameras I add, more slow access becames. Just while waiting while ZM add one more camer (I've 16 CCTV cameras attached to 2x8 port BTTV cards. Please note that most of the cameras might be in MONITOR mode, or even in NONE - anyway it slows down. While ZM processes does not eat too much CPU time, MYSQL eats 50%-60% and more. Please look at the DB structure, I suppose proper indexing or DB reorganization would make ZM hugely more responsive.
Regards,
Anton.
Database not optimized!
-
jameswilson
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
after adding cams or restarting zm, it checks the db structure and runs zmfilter which will use all resources for a period but then it will stop. Addiin monitors is not a regular thing and slow down is expected but it i sonly short lived. The db structure is very efficient for the vastamounts of data collected
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Adding extra 512M of RAM made PC more responsive. Find swapping.
PS: But anyway some sort slowdown exist while working with interface, not as before though.
PPS. Once again met the situation, while perl ZM script occupied port 80 and apache 2 diyed, this could be cured by stopping zm and starting apache and starting zm again
PS: But anyway some sort slowdown exist while working with interface, not as before though.
PPS. Once again met the situation, while perl ZM script occupied port 80 and apache 2 diyed, this could be cured by stopping zm and starting apache and starting zm again