Zoneminder Web Interface is really slow

[gdulisse]

Anyone see the same problems I do, lots of "Waiting for <your domain or IP>..." that can take 10 or 20 or more seconds, especially when you want to view the Log link.

Is there any way to make this faster on the front end. I have a fast intel i5 processor and lots of ram and an SSD on this system.

Any help is appreciated.
THanks

[Carrier82]

How high is the system load?

[gdulisse]

How high is the system load?

Hi and thanks for replying.

Below 2.0, and it is using an intel i550 (2 cores). 1.43 right now and when I login it takes forever in IE and Firefox to display the console. 10+ seconds or more.

[jonathancnewcomb]

I have not seen this before with my install....are you using Apache web server? Perhaps a reverse domain lookup attempt??

[Flasheart]

Several possibles spring to mind:

Free memory is low.
CPU is high. 1.43 on a 2.0 nominal system will still affect performance. SSD won't make much difference in this case since the delays in loading ZM's console are mostly in ram as well as disk (a large number of sql queries are required).
Apache is badly configured. Check logs and google for guides.
mysql is badly configured and may benefit from optimising. Google for guides.
The Mysql tables are corrupted and delaying. (Unlikely, easiest to use phpmyadmin to check)

One thing that has helped me a lot in similar situations is simply installing apache2-mpm-worker which is a drop-in replacement for the unthreaded apache that debian (at least) installs by default.

[gdulisse]

I have not seen this before with my install....are you using Apache web server? Perhaps a reverse domain lookup attempt??

Thanks looked at my conf and Revers Name lookups are disabled.
Will diagnose to see what else it could be.

[gdulisse]

Several possibles spring to mind:

Free memory is low.
CPU is high. 1.43 on a 2.0 nominal system will still affect performance. SSD won't make much difference in this case since the delays in loading ZM's console are mostly in ram as well as disk (a large number of sql queries are required).
Apache is badly configured. Check logs and google for guides.
mysql is badly configured and may benefit from optimising. Google for guides.
The Mysql tables are corrupted and delaying. (Unlikely, easiest to use phpmyadmin to check)

One thing that has helped me a lot in similar situations is simply installing apache2-mpm-worker which is a drop-in replacement for the unthreaded apache that debian (at least) installs by default.

So brought up top and just looked at the process queue while I logged in. mysql goes right to the top and is at 97-98% CPU for quite a while. So looks to be a mysql issue. I will diagnose this further.

Thanks for your input.

Giancarlo

[gdulisse]

Several possibles spring to mind:

Free memory is low.
CPU is high. 1.43 on a 2.0 nominal system will still affect performance. SSD won't make much difference in this case since the delays in loading ZM's console are mostly in ram as well as disk (a large number of sql queries are required).
Apache is badly configured. Check logs and google for guides.
mysql is badly configured and may benefit from optimising. Google for guides.
The Mysql tables are corrupted and delaying. (Unlikely, easiest to use phpmyadmin to check)

One thing that has helped me a lot in similar situations is simply installing apache2-mpm-worker which is a drop-in replacement for the unthreaded apache that debian (at least) installs by default.

So brought up top and just looked at the process queue while I logged in. mysql goes right to the top and is at 97-98% CPU for quite a while. So looks to be a mysql issue. I will diagnose this further.

Thanks for your input.

Giancarlo

Installed mysqltunner and will monitor but I am really puzzled why it is so slow. It litteraly takes over 20 seconds after logging in to display the console. There are 8700 events total for all my cameras.

[gdulisse]

Several possibles spring to mind:

Free memory is low.
CPU is high. 1.43 on a 2.0 nominal system will still affect performance. SSD won't make much difference in this case since the delays in loading ZM's console are mostly in ram as well as disk (a large number of sql queries are required).
Apache is badly configured. Check logs and google for guides.
mysql is badly configured and may benefit from optimising. Google for guides.
The Mysql tables are corrupted and delaying. (Unlikely, easiest to use phpmyadmin to check)

One thing that has helped me a lot in similar situations is simply installing apache2-mpm-worker which is a drop-in replacement for the unthreaded apache that debian (at least) installs by default.

So brought up top and just looked at the process queue while I logged in. mysql goes right to the top and is at 97-98% CPU for quite a while. So looks to be a mysql issue. I will diagnose this further.

Thanks for your input.

Giancarlo

Installed mysqltunner and will monitor but I am really puzzled why it is so slow. It litteraly takes over 20 seconds after logging in to display the console. There are 8700 events total for all my cameras.

So looked at this and am stumped. Does anyone know how to recreate the ZM database from scratch?

[Flasheart]

If you're not a mysql expert (I'm not!) then phpmyadmin is a useful tool - it'll allow you to click a button to repair a broken mysql table, backup, inspect - lots of stuff. (Don't expose it to the internet though, it's quite heavily targetted by the bad guys). Most tables are repairable that way without knowing a lot.

For nuking totally, drop the table and recreate it - there may be a mysql.txt or similar, check the distro's readme, files or if built from hand, the source.

Also removing zoneminder entirely - "apt-get remove zoneminder --purge" might do the job on debian or ubuntu, although checking the sql table has gone too would be good. Then of course, reinstalling and reconfiguring the cameras.

[gdulisse]

If you're not a mysql expert (I'm not!) then phpmyadmin is a useful tool - it'll allow you to click a button to repair a broken mysql table, backup, inspect - lots of stuff. (Don't expose it to the internet though, it's quite heavily targetted by the bad guys). Most tables are repairable that way without knowing a lot.

For nuking totally, drop the table and recreate it - there may be a mysql.txt or similar, check the distro's readme, files or if built from hand, the source.

Also removing zoneminder entirely - "apt-get remove zoneminder --purge" might do the job on debian or ubuntu, although checking the sql table has gone too would be good. Then of course, reinstalling and reconfiguring the cameras.

Thanks, I'm not an expert but am pretty good at all the unix/tech stuff. I think I will find out how to do a full backup and restore of the mysql database.

My strategy with this is to recreate the entire ZM database and then I will restore it (so try MyISAM again, hoping it is just a corrupt DB). If that does not work then I will recreate it but this time as a MyInnoDB and see if that fixes the performance issues.

I am a bit surprised no one else has seen this happen. 30+ seconds to do anything and mysql process is taking almost 100% of one CPU during that time.

Giancarlo

[jonathancnewcomb]

I admin a number of MySQL boxes and unfortunately I have run across this in the past. Quite annoying to say the least. You are looking for bug 34312 as reported to MySQL, ensure you are encountering this box and follow the work around provided by the developers. The bug report is below:

http://bugs.mysql.com/bug.php?id=34312


After I completed the recommended mitigation items, I have not encountered a problem since.

[gdulisse]

I admin a number of MySQL boxes and unfortunately I have run across this in the past. Quite annoying to say the least. You are looking for bug 34312 as reported to MySQL, ensure you are encountering this box and follow the work around provided by the developers. The bug report is below:

http://bugs.mysql.com/bug.php?id=34312


After I completed the recommended mitigation items, I have not encountered a problem since.

Found what the problem was.
So logging to the database is a really bad decision. I had over 90K messages and it was slowing everything down. I disabled LOG_LEVEL_DATABASE in my options and things were faster. To make it even faster I switched over to INNODB for the following tables: Events, Frames, Logs

sudo service zoneminder stop
mysql -uroot -p
use zm;
ALTER TABLE Frames ENGINE = INNODB;
ALTER TABLE Events ENGINE = INNODB;
ALTER TABLE Logs ENGINE = INNODB;

I also dropped and recreated the logs table since it was so full.

So a big warning do not use the database logging it is a resource hog and will adversly affect your zoneminder performance. My console comes up in 2 seconds now.

Thanks for all your help and comments it is appreciated.
Giancarlo