[ZBX-6757] Monitoring->triggers page is too slow on systems with a lot of triggers because of seq scan of triggers table Created: 2013 Jul 01  Updated: 2017 May 30  Resolved: 2017 Feb 08

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Frontend (F)
Affects Version/s: 2.0.7rc1, 2.1.0
Fix Version/s: None

Type: Incident report Priority: Major
Reporter: Alexey Pustovalov Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: dbpatches, performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MySQL


Issue Links:
Duplicate
duplicates ZBXNEXT-2495 Index by value and lastchange in trig... Closed

 Description   

We get triggers in PROBLEM state (value = 1) and triggers in OK state (value = 0 AND clock>= NOW() - INTERVAL 30 MINUTES). We have no index by clock column for triggers table. So this query can take a lot of time.



 Comments   
Comment by Alexey Pustovalov [ 2013 Jul 01 ]

an example:

SQL (157.802031): SELECT t.triggerid,t.lastchange FROM triggers t WHERE EXISTS (SELECT NULL FROM functions f,items i,hosts_groups hgg JOIN rights r ON r.id=hgg.groupid AND r.groupid='100100000000041' WHERE t.triggerid=f.triggerid AND f.itemid=i.itemid AND i.hostid=hgg.hostid GROUP BY f.triggerid HAVING MIN(r.permission)>=2) AND NOT EXISTS (SELECT NULL FROM functions f,items i,hosts h WHERE t.triggerid=f.triggerid AND f.itemid=i.itemid AND i.hostid=h.hostid AND (i.status<>0 OR h.status<>0)) AND t.status=0 AND t.flags IN ('0','4') AND ((t.value=1) OR ((t.value=0) AND (t.lastchange>1372322468))) AND t.triggerid BETWEEN 100000000000000 AND 199999999999999
CAPIObject->get() -> CAPIObject->__call() -> czbxrpc::call() -> czbxrpc::callAPI() -> call_user_func() -> CTrigger->get() -> DBselect()

______ Sub-Part 1 ______  ____________ Sub-Part 2 ____________  _________ Sub-Part 2 __________
Select Type: PRIMARY      Select Type: DEPENDENT SUBQUERY       Select Type: DEPENDENT SUBQUERY
      Table: t                  Table: f                              Table: i
 Partitions:               Partitions:                           Partitions:
       Type: range               Type: ref                             Type: eq_ref
 Poss. Keys: PRIMARY       Poss. Keys: functions_1,functions_2   Poss. Keys: PRIMARY,items_1
      Index: PRIMARY            Index: functions_1                    Index: PRIMARY
 Key Length: 8             Key Length: 8                         Key Length: 8
  Index Ref:                Index Ref: zabbix.t.triggerid         Index Ref: zabbix.f.itemid
  Row Count: 289498         Row Count: 1                          Row Count: 1
    Special: Using where      Special: Using where                  Special:

_______________ Sub-Part 2 _______________  _________ Sub-Part 2 __________
Select Type: DEPENDENT SUBQUERY             Select Type: DEPENDENT SUBQUERY
      Table: hgg                                  Table: r
 Partitions:                                 Partitions:
       Type: ref                                   Type: ref
 Poss. Keys: hosts_groups_1,hosts_groups_2   Poss. Keys: rights_1,rights_2
      Index: hosts_groups_1                       Index: rights_2
 Key Length: 8                               Key Length: 8
  Index Ref: zabbix.i.hostid                  Index Ref: zabbix.hgg.groupid
  Row Count: 1                                Row Count: 1
    Special: Using index                        Special: Using where

Because of all rows can be 0 and 1 (a little bit it can be 2 (unknown state)), MySQL parse all rows in triggers table.

After the patch for indexes:

alter table triggers drop index triggers_2, add index triggers_2(value,lastchange);

SQL total time is 0.85 seconds instead of 160 seconds.

Comment by Oleksii Zagorskyi [ 2017 Feb 08 ]

Already implemented in ZBXNEXT-2495 for 3.0.
Closed.

Generated at Wed Apr 24 00:10:57 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.