CPU Last - Sysinfo: PHP immer auf Anschlag

[Doenges]

Hallo,

eine Frage zu der Auslastung einer EDOMI Installation. Woher kommt eine hohe PHP Last genau? Das Bild zeigt die Statistik meiner Installation als eine Visu online ist.

Ich habe hierzu nichts im Forum noch im Wiki gefunden, würde gerne wissen ob es hier Optimierungspotenzial gibt.

Danke für die Hilfe.


Bildschirmfoto 2018-05-01 um 11.58.19.png

[Doenges]

Könnte die "76" für 76 Elemente in der Visu stehen?

[Doenges]

Bildschirmfoto 2018-05-01 um 12.03.39.png Der Vollständigkeit halber hier ein Bild mit mehr Details zu meiner aktuellen Auslastung:

[jonofe]

Die 76 ist die Anzahl der laufenden PHP Prozesse, d.h. das Ergebnis von

ps auxw | grep php

Allerdings gibt es nicht zwangsweise eine Abhängigkeit zwischen Anzahl PHP Prozesse und hoher Prozessorlast.

Was sagt denn ein

top

Nach starten von top 'c' drücken, damit du den gesamten Prozessnamen siehst. Welcher Prozess erzeugt denn hier die hohe Last?

[Doenges]

Oh...das hilft schonmal!

die SQL DB scheint hier viel CPU Zeit zu beanspruchen. Kann da was machen?

Bildschirmfoto 2018-05-01 um 12.51.51.png

[jonofe]

Ich würde vermuten, dass es eine Logikschleife ist. Ggf. mal auf das erste Widget rechts von der Admin Startseite schauen, welche iKOs/GAs dort oft aktualisiert werden. Das könnte ein Hinweis auf eine Ursache einer Logikschleife geben.

[Doenges]

Super Tip, Hat ein wenig geholfen - CPU Last ist immer noch hoch aber zumindest konnte ich so ein paar Logiker optimieren. Danke!!

[saegefisch]

...weil das Thema in den letzten Tagen recht gehäuft kam - und der eine oder andere es noch nicht weiß oder wieder vergessen hat:

• Man kann jede/alle Logik-Seite inaktiv (jeweils eine Seite komplett) setzen (mit anschließendem Reaktivieren des Projekts), um so die Ursache einzukreisen und um dann nach und nach wieder anzuschalten (eben jedes Mal mit Reaktivierung).
• Alternativ kann man Logiken auch mit Schaltern versehen, damit man sie ohne Reaktivierung im Betrieb an/ausschalten kann. Dies ist zum einen über zusätzliche KO bei allen LBS mit einem Trigger und Aktivierungs-Eingang ("läuft, wenn A1 = 1").
  Ergänzung: Hier kann man zumindest im Liveview auch mal mit einem 0-Wert eingreifen, um Logiken zeitweise auszuschalten und die CPU-Last zu prüfen
• Oder/und man nutzt vielfältig den LBS 14000029 "Sperre" (reicht jeden E2-Wert 1:1 an A1 weiter, wenn E1>0). Darüber kann ich fast alle meine Logiken über ein paar Logik-KO an und abschalten im laufenden Betrieb, die bei Eintreffen eines Telegramms aktiv werden.

So hat man auch Logik-Schleifen schnell im Griff/entschärft/erkannt.

[Brick]

wir bräuchten einen LogikschleifenCounter-LBS.. der zb die Durchläufe pro Min ausgibt.. wenn dieser Wert (ungewollt) sehr
hoch ist, liegt was im Argen

Wär sicherlich einfach zu erstellen...

[saegefisch]

Irgendwie versehe ich nicht, warum hier „plötzlich“ so viele Leute so viele Logikschleifen haben...

So ein Zähler ist sicher irgendwie nett, aber wenn man mit etwas bedacht an die Sache heran geht, gibt es gar keinen Grund dafür. Es gibt Werkzeuge und Indikatoren, manchmal muss man halt mal selber selbstkritisch mit dem ins Gericht gehen, was man gerade gemacht hat. Das fällt doch meist sofort ins Auge, wenn da was aus dem Ruder läuft.

Aber es wird doch keiner 3 Tage Myriaden Logiken bauen und dann „plötzlich“ am Ende feststellen, dass man nicht mehr weiß, wo... ? Oder doch?
sorry, just my 3 Cents...

Btw: in der Basis-Konfiguration gibt es einen Begrenzung-Parameter gegen Logik-Schleifen. Einen Zähler gibt es also wohl schon im Backend. Man könnte also eine worst-of-Liste anbieten, die 10 Logiken, mit den derzeit höchsten Schleifen-Frequenzen... Und wenn meine Werte schlechter sind, als bei anderen hier im Forum, brauch' ich dringend eine schnellere CPU für den Kampf um den höchsten worst-of-Wert... Quasi das Dragster-Rennen unter den Logik-Schleifen...die performanteste Logik-Schleife gewinnt! Spaß beiseite, der Zähler müsste tatsächlich ja schon da sein...

irgendwas ist halt immer...

[Doenges]

Alles hilfreiche Tips - jeder kommt mit einen verschiedenem Paket an Skills an dieses Projekt - manche mit viel Wissen zu Logik, PHP etc...andere mit viel Interesse an der Sache an sich aber wenig wissen zu Logik. Ich hatte zwar Boolesche Algebra aber mit Logiken in der Praxis hat das erstmal nur bedingt was zu tun. Man lernt durch ausprobieren und Input aus der Community.
Mir hat es geholfen die CPU Last von ca. 70% auf ca. 50% zu senken! Aus diesem Grund ein Danke an Alle hier in dieser Runde.

[saegefisch]

...natürlich ist das auch richtig, was Du sagst und ich wollte auch nicht böse-bös sein, sondern gerade denen, die weniger Vorwissen/Erfahrung mitbringen charmant-bös-augenzwinklernd den Blick auf das drumherum nahe bringen. Und für alle gilt - egal mit welchem Rucksack man kommt - genau, was Du sagst:

Man lernt durch ausprobieren und Input aus der Community.

Der Tenor meines letzten Beitrags ist im Lichte Deiner Rückmeldung: Lieber ein Schritt nach dem anderen und öfter schauen, was es für Folgen hat; neben der eigentlchen "Nutz-Ergebnis" der Logik eben auch den Bus- und KO-Verkehr und die CPU mal eines Blickes würdigen (erstes Widget rechts und die beiden Widges gang links). Dazu sich selbst mit Schaltern/Logiken an/ausschalten helfen. Wenn man es richtig wissen will: Alle ausschalten und nach und nach wieder anschalten und sehen, wo der Sprung kommt. Und als Hilfe auch gut (habe ich selber meist auf einem weiteren Reiter offen), damit man parallel (!) im Liveview ändern und die CPU beobachten kann: Der zusätzliche Status-User für die Widgets mit https://<edomi>/admin/?login=status&pass=status

Weiterhin viel Spaß und Erfolg!