KNX DISCONNECT_REQUEST kurz nach Mitternacht

[Wingfighter]

Hallo in die Runde

Ich verfolge diese Diskussion schon eine Weile, da der beschriebene Fehler auch bei mir bisweilen auftaucht.
Um der Ursache etwas näher zu kommen, möchte ich meine Erkenntnisse gern mit Euch teilen:

Zunächst habe ich mit tcpdump im fraglichen Zeitraum ( 00:00:50 - 00:01:05 ) den Netzwerkverkehr zwischen dem KNX-Gateway (MDT) und Edomi mitgeschnitten.
Die Darstellung in Wireshark sieht dann so aus. (KNX-GW: 192.168.0.197; EDOMI: 192.168.0.154)

edomi4_wireshark.png

Paket 240 und 241 sind noch normale Datenpakete. 00:00:59 sendet das KNX-Gateway ein Request, das nicht beantwortet wird (Paket 243). Daraufhin wird die Anfrage knapp eine Sekunde später noch einmal wiederholt (Paket 244). Weil wieder keine Antwort von Edomi kommt, fordert das Gateway wiederum eine Sekunde später die Beendigung der Verbindung an ( Paket 246 ). Diese Anforderung wird mit Paket 251 und 252 bestätigt, obwohl Edomi vorher noch einmal versucht sich mit dem Gateway zu unterhalten. Da die Verbindung aber schon abgebaut ist, wird in Paket 255 (hier nicht zu erkennen) mit der Fehlermeldung geantwortet, dass der angesprochene Kommunikationskanal nicht mehr existiert.
Die nicht mehr stehende Verbindung quittiert der Edomi-Server mit einem ICMP-Paket (Port unreachable) (Paket 253). Diese Fehlermeldung wird ins Fehlerlog von Edomi eingetragen. (Uhrzeit: 00:01:02)

image_63218.png

Was passiert zu dem Zeitpunk in Edomi?

image_63221.jpg

In der EDOMI-Statistik ist zu erkennen, dass die CPU nahezu zu 100% beschäftigt ist. Das Kommando top zeigt, dass der Prozess mysqld die CPU beschäftigt.
Das wiederum ist wahrscheinlich auf den Backup-Prozess, der um diese Zeit startet, zurück zu führen, wie jonofe hier vermutet.

Warum kommt dieser Fehler nicht jede Nacht?

Der Fehler kommt nur zum tragen, wenn genau im oben genannten Zeitraum zwischen Gateway und Edomi Daten ausgetauscht werden.
Bei mir ist die Wahrscheinlichkeit für ein Datentelegramm sehr hoch, da der Stromzähler alle paar Sekunden seinen Zählerstand und die aktuelle Leistung übermittelt.
Als ich diese Übertragung noch nicht implementiert hatte, gab es so gut wie nie den beschriebenen Fehler.

Welche Lösungen kommen in Frage?

1. Man könnte dem mysql-Prozess etwas an Priorität entziehen, um der CPU noch Zeit für andere Aufgaben zu lassen. Das wirkt sich aber mit Sicherheit auf die Gesamtperformance des Systems aus.

2. Edomi könnte während des Backup-Prozesses gezielt die Netzwerkverbindung beenden. Allerdings werden dann sicher KNX-Datenpakete im Gateway verworfen und der WAF leidet, weil ausgerechnet zu dem Zeitpunkt das Tablet an der Wand das Kommando "Alle Lichter aus" o.ä. nicht ausführen möchte. ;-)

3. Wir leben damit, dass dieser Fehler bei einer ungünstigen Konstellation Backup vs. Datenverkehr auftreten kann.

Gruß wingfighter

[Nanosonde]

Ich verfolge diese Diskussion schon eine Weile, da der beschriebene Fehler auch bei mir bisweilen auftaucht.
Um der Ursache etwas näher zu kommen, möchte ich meine Erkenntnisse gern mit Euch teilen:

Hi!

Könntest Du noch kurz folgende Fragen beantworten?

1) Auf welcher HW läuft Edomi mit CentOS6 bei Dir?
2) Welchen Linux-Kernel nutzt Du? ("uname -a")
3) Wurde die CentOS6 Installation auf den letzten Stand gebracht? Oder ist es noch genau die Version, mit der Christian arbeitet? ("lsb_release -a")

Achso: Deine Screenshots kann ich leider nicht sehen. Irgendwas stimmt mit den Links nicht.

[crewo]

Man könnte auch die Datenbank als Master-Slave betreiben und vom Slave wird dann das Backup gemacht, mit niedriger Prio. Somit ist der Master nicht betroffen und edomi hat weiterhin vollen Zugriff auf die DB. Der Slave ist nicht produktiv und dient nur als Vorhalte-DB für das Backup, natürlich ersetzt auch ein Slave auf keinen Fall ein DB-Backup.

Vorteil ist lediglich die Entkopplung von der produktiven Datenbank, alles sehr zuverlässig und selbst verwaltet durch mysql. Nachteil ist doppelter Speicherbedarf auf der Festplatte und doppelte Schreibzugriffe, allerdings nur für die DB selbst.

[gaert]

Die Bus-Kommunikation/Logik/etc. wird ohnehin als Kopie im RAM "betrieben" und wird vom Backup nicht angerührt. Vermutlich ist Deine HW irgendwie zu schwach?! Ich habe diese Probleme jedenfalls nicht - irgendwie verteilt CentOS alles brav auf die 2 Cores...

[crewo]

gaert d.h. die DB wird nicht gelockt und damit Schreibzugriffe erst einmal verhindert während dem Backup? Die Kopie im RAM nützt dir ja nur bei lesenden Zugriffen etwas. Ich kenne mich da leider nicht so tief aus, wenn ich aber aus der Praxis kopiere wird das bei großen verteilten DB so gemacht wie oben beschrieben (als vermutlich 1 Lösung von 1000 möglichen).

[Wingfighter]

Achso: Deine Screenshots kann ich leider nicht sehen. Irgendwas stimmt mit den Links nicht.

Hab' die Links der Bilder noch einmal korrigiert. Sind sie jetzt zu sehen?

Frage 1-3 kann ich Dir nachher beantworten.

Gruß wingfighter

[jonofe]

Welche Lösungen kommen in Frage?

1. Man könnte dem mysql-Prozess etwas an Priorität entziehen, um der CPU noch Zeit für andere Aufgaben zu lassen. Das wirkt sich aber mit Sicherheit auf die Gesamtperformance des Systems aus.

2. Edomi könnte während des Backup-Prozesses gezielt die Netzwerkverbindung beenden. Allerdings werden dann sicher KNX-Datenpakete im Gateway verworfen und der WAF leidet, weil ausgerechnet zu dem Zeitpunkt das Tablet an der Wand das Kommando "Alle Lichter aus" o.ä. nicht ausführen möchte. ;-)

3. Wir leben damit, dass dieser Fehler bei einer ungünstigen Konstellation Backup vs. Datenverkehr auftreten kann.

4. und vermutlich sinnvollste Lösung: Wir dimensionieren unseren EDOMI Server etwas größer und versuchen nicht das letzte Viertel-Watt zu sparen.
Uns muss dann natürlich bewusst sein, dass wir möglicherweise für die Insolvenz des Furto S900 Händlers auf ebay verantwortlich gemacht werden.

[gaert]

crewo
Klar werden die Tables mit einem lock versehen. Aber die Table für die KNX-Kommunikation nicht - die "läuft" vollkommen unabhängig und wird auch nicht ins Backup mit einbezogen.

EDIT:
Meine Peak-CPU-Last liegt bei 57% (seit Start). Dies schließt natürlich das Backup mit ein. Wie Du siehst, sind da noch genug Reserven Also wird Deine HW einfach zu schwach sein, um Backup und gleichzeitigen Betrieb zu stemmen...

Bildschirmfoto 2017-07-25 um 11.39.32.png

[crewo]

Alles klar, danke und gut zu wissen! Wenn Werte nun aber in ein Archiv geschrieben werden, gibt es da ein Problem? Oder kannst du die DB tatsächlich ausschließen wegen gelockt durch Backup?

[gaert]

Die Archive bekommen auch ein (read-)lock - das geht nicht anders, denn sonst lässt sich kein Backup anfertigen. Dies sollte aber kein Problem sein, da die entsprechenden Inserts in einer Queue landen sollten. Musst Du mal ausprobieren - ist nur Theorie

[crewo]

Naja, der Lock wäre umgehbar über Master-Slave, aber vermutlich die berühmte Kanone auf Spatzen. Ich hab leider auch ca. 1-2x pro Woche den Fehler im Log, auch immer zur Backup-Zeit. System ist ein APU 2C4 mit 80 GB SSD, da gibt es auch keinerlei Performance-Probleme wie hier beschrieben. Daher ja mein Verdacht mit der DB.

[Simone]

Ich habe schwache Hardware und noch nie das 0h Problem gehabt. Allerdings habe ich nicht so viele Archive und LBSen und nur LSBen ohne zusätzliche Installation. Muß es dann eine große DB sein, dass die schwache Hardware ein Problem bekommt?

Ich hatte letztens 10 Fehler als ich eine andere Linux VM (die ein LBS erreichen muß) ausgeschaltet war, kann aber nur Zufall sein ich habe es nicht mehrfach getestet da diese Fehler bei mir eigentlich nicht mehr auftauchen.

[gaert]

Es gibt natürlich zig Backup-Strategien für mySQL - am "sichersten" wäre wohl ein Dump der Daten. Aber das ist langsam und unhandlich (Restore), daher meine Entscheidung für das simple Kopieren der Dateien.

Übrigens kann man das Backup auch abschalten Und auch per Logik triggern, z.B. um den Zeitpunkt auf einen anderen (per ZSU) zu verlegen. Wer mag, könnte sich auch einen LBS schreiben der die Daten dumped oder so

[mfd]

Ich habe schwache Hardware und noch nie das 0h Problem gehabt.

Hatte bisher auch noch nie das 0h Problem, weder mit dem o.g. Futro S900, noch mit der aktuellen Hardware. Allerdings haben beide auch einen Realtek Netzwerk Chip. Falls es sich auf eine bestimmte Hardware-Software Kombination (Treiberproblem?) beschränkt wäre eine Statistik der verwendeten Hardware, Kernelversion und Auftreten des Fehlers vielleicht hilfreich um etwas einzugrenzen.

[starwarsfan]

Hallo miteinander,

also ich kann mir nicht so recht vorstellen, dass das Problem an zu schwacher Hardware liegt und vermute es auch sehr viel mehr bei der verwendeten Hardware selbst bzw. der Konstellation der Komponenten. Das Disconnect-Problem habe ich auch sporadisch nachts, kann aber kein Schema erkennen, an welchen Tagen es auftritt.

Meine Edomi-Instanz läuft bei normalem Betrieb laut Edomi-CPU-Monitor bei ~5-7%. Direkt nach einem Edomi-Neustart sind es für ein paar Sekunden ~70%, was wohl an der Initialisierung resp. dem ersten Lauf der LBS'e liegt:

2017-07-25-CPU-Edomi-Restart.png

Der Peak dabei ist dann auch schonmal bei 98%:

2017-07-25-CPU-Edomi-Peak.png

Edomi selbst ist bei mir eine Proxmox-VM mit 4G RAM und zwei Cores auf einem IBM x3850M2 mit 128G RAM, 4x QuadCore-Xeons zu 2.93GHz. Auf der Maschine laufen noch ein paar weitere VMs aber das Blech langweilt sich mehrheitlich.