Graph Template Editing very slow

[MU-IT]

Folks,

I'm experiencing page load issues when editing graph templates (/cacti/graph_templates.php?action=template_edit).

Even changing a color or changing the order of Graph Items takes 30-45 seconds.

No other part of my cacti installation takes as long.

I have changed the index order of the colors.php, and added a bunch of colors to the colors table, but that's all i can think of that might have any effect on the graph templates.

any ideas?

Stats:

Date Mon, 08 Feb 2010 09:41:46 -0500
Cacti Version 0.8.7e
Cacti OS win32
SNMP Version NET-SNMP version: 5.4.2.1
RRDTool Version RRDTool 1.2.x
Hosts 429
Graphs 3230
Data Sources Script/Command: 11
SNMP: 76
SNMP Query: 2820
Script - Script Server (PHP): 70
Script Query - Script Server: 221
Total: 3198
Poller Information
Interval 300
Type cmd.php
Items Action[0]: 5167
Action[1]: 11
Action[2]: 312
Total: 5490
Concurrent Processes 10
Max Threads 5
PHP Servers 5
Script Timeout 100
Max OID 55
Last Run Statistics Time:181.8117 Method:cmd.php Processes:10 Threads:N/A Hosts:411 HostsPerProcess:42 DataSources:5490 RRDsProcessed:2899

[BSOD2600]

Enabled MySQL's Query cache yet? If not, do so and that should help some.

How large is the color table now?

[MU-IT]

Enabled MySQL's Query cache yet? If not, do so and that should help some.

How large is the color table now?

Color table is approx 400 rows, 7.8kb per MySQL Administrator. The initial template edit page loads quickly, but edits from there are slow.

Machine is a XEON 3ghz (quad core) with 14gb RAM.

Code: Select all

results from "show variables like 'query%';

+------------------------------+------------+
| Variable_name                | Value      |
+------------------------------+------------+
| query_alloc_block_size       | 8192       |
| query_cache_limit            | 1048576    |
| query_cache_min_res_unit     | 4096       |
| query_cache_size             | 1048576000 |
| query_cache_type             | ON         |
| query_cache_wlock_invalidate | OFF        |
| query_prealloc_size          | 8192       |
+------------------------------+------------+
7 rows in set (0.00 sec)

I've had this setup for awhile (1.5 years roughly), and don't remember setting query_cache, but it looks like it has been done.

[BSOD2600]

1) What mysql and php versions?
2) Considered reversing the index changes to the color table? What did you exactly do? The additional colors shouldn't be a problem, as I've added those too with no problems.

[MU-IT]

1) What mysql and php versions?
2) Considered reversing the index changes to the color table? What did you exactly do? The additional colors shouldn't be a problem, as I've added those too with no problems.

1) PHP Version 5.2.9, MYSQL 5.1.33.

2) I followed http://forums.cacti.net/viewtopic.php?t ... ght=colors after I added the additional colors from that same thread.

[BSOD2600]

Hmm I believe that should all be fine. Using MySQL administrator, take a look at the Query cache stats before/during graph editing. Any noticeable changes?

When you say things are slow... to just open the initial graph template or each one if its items? Are other graph templates/items slow when this occurs? What makes it faster again?

If you turn on error logging in php.ini, anything stand out?

[MU-IT]

Hmm I believe that should all be fine. Using MySQL administrator, take a look at the Query cache stats before/during graph editing. Any noticeable changes?

When you say things are slow... to just open the initial graph template or each one if its items? Are other graph templates/items slow when this occurs? What makes it faster again?

If you turn on error logging in php.ini, anything stand out?

I haven't had time to try these suggestions yet, hopefully this afternoon.

I can load the page to begin editing normally, I can click a graph item to make a change and it loads normally. When I attempt to save my changes it always takes a long time, sometimes timing out.

[BSOD2600]

Yea, enable the php.ini logging, look in the web server logs and keep an eye on mysql admin performance stats to try and get an idea where the issue is.

[MU-IT]

Yea, enable the php.ini logging, look in the web server logs and keep an eye on mysql admin performance stats to try and get an idea where the issue is.

I do see a small bump in the performance stats on SQL, but nothing that would lead me to believe it was an issue. it was certainly far less than a normal polling cycle.

apache logs pointed me in a different direction, but I've solved the errors there, and it still happens.

i did notice, and i imagine this to be perfectly normal, that editing templates that are heavily utilized takes longer to update than those that aren't.

I also noticed that edits take longer when a polling cycle happens, but that's sensible.

If it's something non-obvious I can live with it taking awhile... i don't do that many template changes.

thanks.

[BSOD2600]

I think I've covered all the main/common things I can think of. Probably going to require some in-depth analysis if you really want to get to the bottom of things. MySQL monitoring/tracing tools might be next...

[npeltier]

Hello,

I'm experiencing the same thing on my servers as well.
The graph template editing gets worse and worse, it always times out now.

Did you find anything usefull ?

Thanks

[lep]

Solved "very slow graph template item edition":

# mysql -u root -p
mysql> use cacti
mysql> ALTER TABLE graph_templates_item ADD KEY (local_graph_template_item_id);

---------------------------------
FreeBSD 10.0-RELEASE amd64
mysql55-server-5.5.36
php53-5.3.28
cacti-0.8.8b_2
spine-0.8.8
rrdtool-1.4.8
net-snmp-5.7.2_3