Hallo zusammen,
vorweg wir nutzen eine "STARFACE Enterprise v5" mit der Build-Version "6.7.0.24".
Seitdem wir unsere Telefonanlage im Zabbix Monitoring hinzugefuegt haben, ist uns aufgefallen, dass die CPU Last tagsueber dauerhaft 100% betraegt.
Wir koennten das Problem mit den UCC Softphone Clients in Verbindung bringen. Bei dem Start weniger Softphone Clients (6-8 Clients) steigt die Last auf ca. 60% an.
Bereits um 8:00 Uhr morgens hat die CPU ihr Limit erreicht, zu dieser Zeit sind ungefaehr 20 UCC Clients aktiv.
Erst nach Ende des Arbeitstages, circa 19:00 Uhr, faellt die Last auf 0,2 -1,3 % ab. Ab 19:00 Uhr sind noch ca. 70 Yealink Telefone mit der Anlage verbunden, diese wirken sich also nicht auf die Last aus.
Blau = Prozessor Load (ab 8 Uhr bis ca 19 Uhr ist die Last 100% oder mehr )
Rot = Online Telefone (UCC + Hardware) > Man sieht das nachdem die Softwaretelefone am Ende des Arbeitstages offline gehen die Last abfaellt.
Gruen = Anzahl eingehender Anrufe
Hier kann man auch sehen, dass die Last bereits vor 8 Uhr steigt (die Meisten beginnen ihren Arbeitstag zwischen 07:30 – 08:00 Uhr) – in dieser Zeit werden die PCs hochgefahren und die UCC Clients automatisch gestartet – es wird aber noch nicht telefoniert.
Wenn man bei der Telefonanlage htop aufruft, kann man erkennen, dass die Auslastung auf Prozesse von tomcat und postgres zurueckzufuehren sind.
Wir haben anschließend häufig via PSQL auftretende Datenbankabfragen ueberprueft.
Im Wesentlichen konnten wir dabei folgendes feststellen:
Es werden hauptsaechlich zwei Queries an die Datenbank uebergeben (je Sekunde laufen etwa 13 Queries dieser Art).
-Typ A: (SELECT idÂ… FROM cdrsummary)
-Typ B: (SELECT count(id)Â… FROM cdrsummary)
## Typ A: Query ##
asterisk=# explain analyze
asterisk-# SELECT id,callid,callbacknumberextern,cdraccountid,calleraccountid,callernumber,callername,calledaccountid,callednumber,calledname,starttime,dialednumber,callbacknumber,incoming,answered,hasvoicemail,deleted,duration,groupcall FROM (SELECT DISTINCT ON(callid, calledaccountid, incoming) id,callid, callbacknumberextern,cdraccountid,calleraccountid,callernumber,callername,calledaccountid,callednumber,calledname,starttime,dialednumber,callbacknumber,incoming,answered,hasvoicemail,deleted,duration,(calledaccountid IN ( 1113,1114)) as groupcall FROM cdrsummary WHERE true AND NOT hasfax AND (cdraccountid = 1657 OR cdraccountid IN (1113,1114)) AND starttime >= 1583571598554 AND starttime <= 1585136317000 ORDER BY callid,calledaccountid,incoming,cdraccountid= 1657 DESC) AS cdr WHERE NOT deleted ORDER BY starttime DESC OFFSET 23220 LIMIT 30;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=5667.42..5667.42 rows=1 width=242) (actual time=603.755..603.762 rows=30 loops=1)
-> Sort (cost=5660.20..5667.42 rows=2888 width=242) (actual time=571.579..602.685 rows=23250 loops=1)
Sort Key: cdr.starttime
Sort Method: external merge Disk: 2856kB
-> Subquery Scan cdr (cost=5378.68..5494.20 rows=2888 width=242) (actual time=390.907..453.680 rows=23331 loops=1)
Filter: (NOT cdr.deleted)
-> Unique (cost=5378.68..5436.44 rows=5776 width=111) (actual time=390.904..445.733 rows=23331 loops=1)
-> Sort (cost=5378.68..5393.12 rows=5776 width=111) (actual time=390.903..408.369 rows=23578 loops=1)
Sort Key: cdrsummary.callid, cdrsummary.calledaccountid, cdrsummary.incoming, ((cdrsummary.cdraccountid = 1657))
Sort Method: external sort Disk: 2912kB
-> Index Scan using cdrsummaryindexstarttime on cdrsummary (cost=0.00..5017.79 rows=5776 width=111) (actual time=2.856..288.719 rows=23578 loops=1)
Index Cond: ((starttime >= 1583571598554::bigint) AND (starttime <= 1585136317000::bigint))
Filter: ((NOT hasfax) AND ((cdraccountid = 1657) OR (cdraccountid = ANY ('{1113,1114}'::integer[]))))
Total runtime: 616.927 ms
(14 rows)
## Typ B: Query ##
asterisk=# explain analyze
asterisk-# SELECT count(id) FROM (SELECT DISTINCT ON(callid, calledaccountid, incoming) id,callid, callbacknumberextern,cdraccountid,calleraccountid,callernumber,callername,calledaccountid,callednumber,calledname,starttime,dialednumber,callbacknumber,incoming,answered,hasvoicemail,deleted,duration,(calledaccountid IN ( 1113,1114)) as groupcall FROM cdrsummary WHERE true AND NOT hasfax AND (cdraccountid = 1657 OR cdraccountid IN (1113,1114)) AND starttime >= 1583571598554 AND starttime <= 1585136327000 ORDER BY callid,calledaccountid,incoming,cdraccountid= 1657 DESC) AS cdr WHERE NOT deleted;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=5501.44..5501.45 rows=1 width=8) (actual time=857.986..857.986 rows=1 loops=1)
-> Subquery Scan cdr (cost=5378.70..5494.22 rows=2888 width=8) (actual time=735.337..855.910 rows=23331 loops=1)
Filter: (NOT cdr.deleted)
-> Unique (cost=5378.70..5436.46 rows=5776 width=111) (actual time=735.336..832.291 rows=23331 loops=1)
-> Sort (cost=5378.70..5393.14 rows=5776 width=111) (actual time=735.335..805.791 rows=23578 loops=1)
Sort Key: cdrsummary.callid, cdrsummary.calledaccountid, cdrsummary.incoming, ((cdrsummary.cdraccountid = 1657))
Sort Method: external sort Disk: 2912kB
-> Index Scan using cdrsummaryindexstarttime on cdrsummary (cost=0.00..5017.82 rows=5776 width=111) (actual time=2.359..487.811 rows=23578 loops=1)
Index Cond: ((starttime >= 1583571598554::bigint) AND (starttime <= 1585136327000::bigint))
Filter: ((NOT hasfax) AND ((cdraccountid = 1657) OR (cdraccountid = ANY ('{1113,1114}'::integer[]))))
Total runtime: 873.317 ms
(11 rows)
#####
Die 'draccountID' kann eindeutig einer Benutzerin zugeordnet werden. Es handelt sich hierbei, um einen einfachen Benutzer, der Mitglied in zwei iQueues ist und mit dem UCC Client telefoniert.
Da diese Abfragen mehrfach gleichzeitig ausgeuehrt werden (natuerlich mit unterschiedlichen User-IDs), stapeln sich die Abfragen in der Datenbank.
Ist dieses Verhalten bekannt oder gar normal?
Vielen Dank im Voraus!
Mit freundlichen Gruessen,
LaVita