Dauerhafte CPU Auslastung der Telefonanlage von 100%

  • 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.


    Starface_Auslastung.png


    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.


    Starface_Auslastung-HTOP.jpg


    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

    5 Mal editiert, zuletzt von LaVita ()

  • Hier nicht. Bei einer Platinum mit zum Teil weit über 100 angemeldeten UCC-Clients und zum Teil 1000 parallelen Calls (durch Überlauf zum Dienstleister) passiert das nicht.


    CDRs schon mal aufgeräumt?

  • Hallo, LaVita,


    ist zwar etwas "offtopic", aber ich bin gerade auch am zabbix dran;
    kannst Du mir bitte sagen, ob und wie Du den Port 10050 der Starface aufgemacht hast?


    Liebe Grüße.
    Martin

  • Kurzer Nachtrag,


    Der Fehler ließ sich auf den damals aktuellen Windows Client zurückführen. Die Datenbankabfragen traten auf, sobald im Client die Liste der Verpassten Anrufe angezeigt wurde. Denn hier wurde Pauschal ALLES Abgefragt was jemals in die Gruppe eingegangen war. Wenn man das jede Sekunde einmal macht, und viele Nutzer Mitglied der selben gruppe sind...naja.... wurde von der Starface später irgendwann gefixt. Wir haben hier aber den genauen überblick verloren, da der Support einfach nicht wirklich gut kommuniziert. In einer der neueren Versionen des Clients steht es jedenfalls in den Fixes mit dabei.


    ms_scheff
    Schau mal bei google nach CentOS 6 add Firewall rule.
    Im Prinzip tut es aber auch die Dokumentation der iptables firewall.
    Warnung hier vor dem Support der Starface: Solche Änderungen werden nicht gern gesehen, und dienen häufig als Sündenbock für Fehler die in der Anlage auftreten, also genau überlegen ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!