-
Problem report
-
Resolution: Fixed
-
Minor
-
4.0.13
-
Sprint 58 (Nov 2019), Sprint 59 (Dec 2019), Sprint 60 (Jan 2020), Sprint 61 (Feb 2020), Sprint 62 (Mar 2020), Sprint 63 (Apr 2020), Sprint 64 (May 2020), Sprint 65 (Jun 2020), Sprint 66 (Jul 2020), Sprint 67 (Aug 2020), Sprint 68 (Sep 2020), Sprint 69 (Oct 2020), Sprint 70 (Nov 2020), Sprint 71 (Dec 2020), Sprint 72 (Jan 2021), Sprint 73 (Feb 2021), Sprint 74 (Mar 2021), Sprint 75 (Apr 2021), Sprint 76 (May 2021), Sprint 77 (Jun 2021), Sprint 78 (Jul 2021), Sprint 79 (Aug 2021)
-
1
Currently, when the problem page (or widget) is loaded, the frontend will additionally get all the alerts from the DB for the problems shown.
Example from debug output.
SELECT a.alertid,a.alerttype,a.clock,a.error,a.eventid,a.mediatypeid,a.retries,a.status,a.userid FROM alerts a WHERE EXISTS (SELECT NULL FROM actions aa WHERE a.actionid=aa.actionid AND aa.eventsource='0') AND a.eventid IN (325501,325567,326570,326956,327258,327564,327612,327649)
If the current problems happen to have a lot of historical alerts, this can result in a very slow query, because there are no limits set to the query.
Is there a way to work around this problem and maybe apply some limits to that query?
- caused by
-
ZBXNEXT-4447 Frontend - Change the severity of a problem
-
- Closed
-
- causes
-
-
- Closed
-
- depends on
-
ZBXNEXT-5878 Enhance permission checking/handling
-
- Closed
-
- is duplicated by
-
ZBX-17527 Dashbooard widget Problems by Severity to high CPU usage
-
- Closed
-
