IP-Symcon reagiert extrem verzögert

Hallo Leute,

ich bin ein wenig am Verzweifeln…

IP-Symcon sieht aus als ob es komplett sauber läuft:

  • keine relevanten Fehlermeldung
  • keine Auffälligkeiten bei den PHP-Threads oder Timern
  • keine Auffälligkeiten bei CPU-Auslastung oder Speicherbelegung des Raspberry Pi 4

Was aber immer wieder auffällt:

  • Webfront reagiert verzögern - teilweise extrem - auf Statusänderungen
  • Man hat den Eindruck das insbesondere Skripte deutliche verzögert ausgeführt werden
  • Einfache Änderungen in der Konsole dauern gefühlte Ewigkeiten, manchmal startet die Webkonsole dabei von selbst neu, manchmal verliert man selbst irgendwann die Geduld und man startet neu

Bin schon regelmäßig dabei des Raspberry Pi komplett neu zu starten

Das hat inzwischen schon Ausmaße angenommen, dass es sehr ärgerlich ist…

Wie könnte ich dem Fehler auf die Schliche kommen?

Joachim

Mein spontaner Tipp: Die Speicherkarte ist dabei, sich zu verabschieden.

Das wäre mein heisser Tipp, um solch schwierigen Probleme auf die Schliche zu kommen: Prometheus Exporter Modul, Dashboard für Grafana, Config für Prometheus

Wenn du in der Konsole auf „Ausführen“ drückst oder per WebFront etwas schaltest: Wird es dann sofort ausgeführt? Ist also nur der Rückkanal betroffen? Wie verhält sich die mobile App in diesem Moment? Werden Ereignisse pünktlich ausgeführt?

paresy

Hallo Paresy,
Hallo DerStandart,

eine „klassische“ Speicherkarte benutzte ich nicht mehr, ist ein SSD. Gleichwohl könnte die ja auch einen defekt haben. Wie könnte man das am Besten ausschließen?

Prometheus habe ich jetzt noch nicht probiert, muss ich mich noch mit beschäftigen.

Wie zeigt sich das Problem an Beispielen:

  • Wenn ich in der Konsole ein Skript ausführe dauert es die ersten Mal mehrere Sekunde, obwohl es nur ein „Einzeiler“ ist. Nach mehrmaliger Ausführung geht es dann gewohnt fix (könnte das etwas mit dem OPCache zu tun haben)
  • Wenn aus dem Webfront den Receiver einschalte dann höre ich sofort das „Klicken“ im Gerät, die Anzeige aktualisiert sich aber erst wesentlich später
  • Wenn ich den Input des Receivers über das Webfront ändere sehe ich das auch sofort am Receiver, aber auch dort tritt eine Änderung des Status im Webfront erst extrem verzögert ein. Über den gewählten Eingang werden aber auch casesensitiv entsprechende Optionen im Webfront sichtbar (skriptgesteuert), das dauert dann so lange dass man geneigt ist das anders auszuführen
  • Wenn ich die LOGO Ausgänge (bei mir ein Modul) steuern passiert das in gewohnter Weise, steuere ich aber damit DMX-Hardware an (Einzeiler-Skript) dauert es gefühlte „Ewigkeiten“. Ich habe es eben mal probiert in der Konsole: Vier mal dauert es sehr lange bis das Skript langsam läuft, danach geht es „Ratzfatz“…

Ich würde es nach den Tests mal so zusammenfassen: Läuft es über Module läuft alles wie gewohnt, ist ein Skript beteiligt dann sind die ersten Durchläufe sehr lang (mehrere Sekunden), irgendwann geht auch das in gewohnter Schnelligkeit.

Joachim

Das klingt tatsächlich sehr, als ob auf dem Rückkanal Verzögerungen sind (oder auf dem WebSocket Teil davon). Wenn du das mit Prometheus einrichten könntest, wäre das Klasse, da wir damit sehr viel mehr Daten bekommen was auf dem System passiert.

paresy

Hallo Paresy,

wo finde ich denn eine Anleitung um das Ganze auf dem Raspberry Pi zu installieren?

Joachim

Hallo Joachim,

deine Fehlerbeschreibung passt zwar nicht genau, daher nur als zusätzlicher Hinweis falls du MQTT im Einsatz hast.

Ich hatte das Problem das alles in IPS stark verzögert ausgeführt wurde. Zum Beispiel ging das Licht nach einem Tastendruck erst nach 5 Sekunden an. Bei mir war es ein MQTT Client (Splitter) der sich nicht mehr mit seinem externen MQTT Server verbinden konnte. Nachdem ich den MQTT Client in IPS deaktiviert hatte war alles wieder schick.

Ralf

Hallo Ralf,

vielen Dank für den Tipp. Ich habe hier nur eine MQTT-Instanz mit dem Tasmato-Modul von KaiS laufen. Die sieht aber unauffällig aus…

Gibt es eine Anleitung zur Installation der oben genannten Tools auf einem Raspberry Pi?

Joachim

Ist das Problem eigentlich auch über den Connect-Dienst nachstellbar? Könnte ich also mich von hier aus auf dein System Konsole + WebFront einloggen und das Verhalten auch sofort sehen? Oder dauert es ein wenig bis dies passiert?

paresy

Hallo Paresy,

hab es gerade noch mal getestet: Wenn ich irgendein Skript aufrufe dauert es bei der ersten Ausführung sehr lange, danach geht es bei jeder Ausführung gefühlt etwas schneller, ab der vierten Ausführung geht es super schnell…
Ich weiß aber nicht ob Du es über den Connect-Dienst sehen kannst…

Joachim

Hallo Leute,

seit einigen Tagen reagiert auch mein IP Symcon 6.1 testing auf einem Raspberry 4 mit 4 GB in einigen Bereichen sehr langsam.
Schalten über das Webfront läuft verzögerungsfrei. Über Alexa ebenfalls.
Die Ausführung von Skripten dauert teilweise mehrere Minuten.
Bei den PHP Informationen finde ich zeitweise nur 1-4 laufende Skripte die rot hinterlegt sind (ich habe max. 50 Skripte zeitgleich zugelassen).
Im Meldungsfenster werden dann auch keine Meldungen mehr angezeigt.
Das Debug-Fenster von dem Homematic Socket bleibt leer, auch wenn ich z.B. die Stehlampe per Alexa schalte und diese auch sofort reagiert. Schalte ich dagegen die Küchenlampe mit einem Homematic 6-fach Taster, wird diese Betätigung in IP Symcon überhaupt nicht erkannt, obwohl die Betätigung auf der Homematic Weboberfläche sofort erkannt wird.
Ein Neustart des Dienstes behebt das Problem nur für einige Minuten.

Hat jemand eine Idee?

Grüße aus dem Norden

Axel

Hallo Axel,

da bin ich ja ein Stück weit beruhigt das ich nicht der Einzige bin…

Prinzipiell läuft alles, aber die teilweise massive zeitliche Verzögerung bei der Ausführung eines Skriptes ist schon nervig. Mittlerweile starte ich mindestens einmal am Tag neu.

Eine typische Szene:Receiver auf „FireTV“, hört man sofort durch leises klicken, das Skript das dabei die Ansicht im Webfront verändert dauert so lange das man schon andere Wege sucht, Beamer ein, regiert sofort, die Leinwand - die automatisch herunterfahren soll wenn der Beamer „An“ meldet wird oft gar nicht mehr ausgeführt. Mehrmals „Stop“, „Öffnen“, „Schließen“ - irgendwann läuft es…manchmal Stop der gestartet Timer dann aber nicht automatisch und die Leinwand fährt so lange herunter bis nichts mehr auf der Rolle ist - der WAF sinkt dabei schneller als der DAX am Black Friday…

Joachim

Dieses Tool ist nicht mehr relevant, da die Metriken des Prometheus Moduls diese ab IP-Symcon 6.1 integriert haben!

Da ich gerade für diese Problemstellung ein kleines Tool entwickelt habe, wollte ich es allen anderen nicht vorenthalten:

Damit kann man recht gut analysieren, was auf dem WebSocket Rückkanal so passiert und wer ggf. der Übeltäter ist.

paresy

@Hallo Paresy,

gibt es das Modul auch für Windows?

Das sollte prinzipiell unabhängig vom Betriebssystem sein, du brauchst allerdings Node.js (https://nodejs.org)

@paresy

hast du eine Idee dazu was wir hier in dem Screenshot von der WebSocket Aufzeichnung erkennen können ?

Kannst du das bitte erklären.

Danke

Hi! Kannst du mir noch kurz sagen, ob das ein Screenshot von deinem Live-System ist? Denn laut Grafana solltest du eher 200 Nachrichten pro Sek. empfangen? Oder stimmt nur die msg/s Berechnung nicht?

paresy

Hi,

ja das ist vom LiveSystem.

Aber nochmal die Frage, warum tauchen dort so viele selbe IDs auf ?

Gruß

Die größten Nachrichten (1. Block) können ja auch alle von der selben ID kommen. Somit können dort mehrfach die selben IDs vorkommen.

Der 2. + 3. Block sind die Anzahl der Nachrichten je nach Nachrichten Typ und dann je nach SenderID.

Bleibt es bei dir immer bei den 5 msg/s? Oder ist das grad nur Zufall?

paresy

Hi,

das verstehe ich nicht so ganz. Wie könnte von der Selben ID zur gleichen Zeit Daten aktualisiert werden?

Womit hängt das zusammen ? Das würde doch heißen das mehrere Verbindungen bestehen ?

Ja, die Anzahl der Nachrichten bleiben relativ so in diesem Bereich.

Gruß