[ZBX-20506] Slow queries when running zbx_dbsync_compare_trigger_tags Created: 2022 Jan 28 Updated: 2024 Apr 10 Resolved: 2022 Apr 21 | 
    |
| Status: | Closed | 
| Project: | ZABBIX BUGS AND ISSUES | 
| Component/s: | Server (S) | 
| Affects Version/s: | 5.4.9 | 
| Fix Version/s: | 6.0.1rc1, 6.2.0alpha1, 6.2 (plan) | 
| Type: | Problem report | Priority: | Trivial | 
| Reporter: | Yurii Polenok | Assignee: | Vladislavs Sokurenko | 
| Resolution: | Fixed | Votes: | 0 | 
| Labels: | database, sync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | 
             postgres 13.5 and timescale 2.1.0 Number of hosts (enabled/disabled)	13957	13847 / 110  | 
	||
| Attachments: | 
                                     | 
        ||||
| Issue Links: | 
                
  | 
        ||||
| Team: | |||||
| Sprint: | Sprint 85 (Feb 2022), Sprint 86 (Mar 2022), Sprint 87 (Apr 2022) | ||||
| Story Points: | 1 | ||||
| Description | 
| 
             Steps to reproduce: 
 Result: slow query: 3.816762 sec, "select distinct tt.triggertagid,tt.triggerid,tt.tag,tt.value from trigger_tag tt,triggers t,hosts h,items i,functions f where t.triggerid=tt.triggerid and t.flags<>2 and h.hostid=i.hostid and i.itemid=f.itemid and f.triggerid=tt.triggerid and h.status in (0,1)" HashAggregate (cost=268197.80..324806.64 rows=1268142 width=50) (actual time=2860.942..3699.744 rows=1147489 loops=1) Its consuming 50MB of mem and writes a temp file to disk for ~120MB each time. It is unlikely that this can be called a bug, but perhaps this query can be optimized. Expected:  | 
    
| Comments | 
| Comment by Vladislavs Sokurenko [ 2022 Feb 01 ] | 
| 
             Thank you for your report, is it possible for you to test the patch ZBX-20506-5.0.diff  | 
| Comment by Yurii Polenok [ 2022 Feb 01 ] | 
| 
             Unfortunately not possible. Our production environment is quite stable and does not allow for tests.  | 
| Comment by Alex Kalimulin [ 2022 Feb 04 ] | 
| 
             Tests show that on systems with big number of triggers and trigger counts there may be 2x config sync speed increase at cost of extra 15% memory consumption in config cache. Let's do this optimization. The change needs to be tested on all supported databases before merging.  | 
| Comment by Vladislavs Sokurenko [ 2022 Feb 17 ] | 
| 
             Implemented in: 
 Updated documentation:  | 
| Comment by Ryan Eberly [ 2022 Feb 24 ] | 
| 
             I don't suppose this could be merged/cherry picked into 5.4.11? I'll be taking that release for the fixes in   | 
| Comment by Vladislavs Sokurenko [ 2022 Feb 25 ] | 
| 
             Unfortunately it cannot be simply cherry-picked to 5.4.11, also 5.4 is non LTS release and support ends soon.  | 
| Comment by Ryan Eberly [ 2022 Feb 25 ] | 
| 
             Ok. I should at least be able to test your updated query from the code in a MySQL shell though. Will move to 6.0 come April during our next 3 month release schedule.  | 
| Comment by Ryan Eberly [ 2022 Feb 25 ] | 
| 
             On Mysql 5.7.34, using the raw sql query changes from the " 
 select triggerid,description,expression,error,priority,type,value,state,lastchange,status,recovery_mode,recovery_expression,correlation_mode,correlation_tag,opdata,event_name,null,null,null,flags from triggers 1956505 rows in set (3.22 sec) Resident Set Size = 971026 
 select triggertagid,triggerid,tag,value from trigger_tag 2480973 rows in set (1.08 sec) Resident Set Size = 243204 
 Previous query SELECTs would take ~66 and 43 seconds, respectively. I didn't benchmark memory. 
 
 
  | 
| Comment by Vladislavs Sokurenko [ 2022 May 02 ] | 
| 
             Thanks for the information, please let us know the results when you upgrade  |