KNX DISCONNECT_REQUEST kurz nach Mitternacht

[Wingfighter]

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")

1) Bei mir läuft EDOMI auf einem Intel NUC DN2820FYKH
2) 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
3) LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.5 (Final)
Release: 6.5
Codename: Final

Die CPU-Last liegt bei dieser Konstellation bei durchschnittlich 13%. Den größten Anteil daran hat die DB.

edomi_CPUlast2.png

edomi_CPUlast.png

[gaert]

starwarsfan
Aber der "Peak" ist doch bei fast 98% - da kann man nicht unbedingt von Langeweile sprechen, zumindest nicht zu "Stoßzeiten" Wie gesagt sind's bei mir 57% Peak, d.h. irgendwie hat mein uralter Atom scheinbar noch mehr Reserven...

Ich könnte mir also schon vorstellen, dass das Problem bei der Auslastung zu suchen ist: Irgendwas beschäftigt die CPU zu fast 100% und dann kann das offenbar recht sensible KNX-Gateway (EDOMI) nicht mehr zeitnah antworten. Nur ein Vermutung, denn trotz intensiver Bemühungen meinerseits konnte ich das Problem noch nie nachstellen... Diese "Seq-Fehler" kenne ich nur aus dem Forum

[Simone]

Da meine Cpu ständig bei 30-40% ist und ab und an in der Visu das rote Fähnchen CPU kommt bin ich sicher dass die Hardware schwach ist dh. das Mitternachtsproblem muß was anderes sein bzw. eine Kombination

Bei mir läuft EDOMI in einer VM auf einem Nuc 3815, Hyper V Core 2016
Centos 6.5 wie in Anleitung ohne Änderungen
Ip Schnittstelle

# maximale Telegramrate
global_knxMaxSendRate=20

Ich hatte in einer früheren Version Edomi + Hyper-V2012 wiederkehrende Fehler (Monster Thread Probleme KNX Router Anbindung) diese Fehler sind bei mir bis auf einen Fall (den ich mir irgendwie erklären kann, siehe oben) schon lange nicht mehr aufgetaucht



Stat1.PNG
Vielleicht so zum Vergleich ein paar Bilder und viele Temp/Feuchte daten aber im Gegensatz zu anderen sicher eine kleine DB
DB.PNG
Stat2.PNG
top.PNG

[starwarsfan]

Hallo Christian

starwarsfan
Aber der "Peak" ist doch bei fast 98% - da kann man nicht unbedingt von Langeweile sprechen, zumindest nicht zu "Stoßzeiten"

Nunja, der Peak kommt ja direkt beim Edomi-Start und von daher weiss ich nicht, wie die Auslastung dann nachts ist. Ich lasse mir via Telegramm Meldungen schicken, wenn die CPU-Auslastung über 90% gestiegen ist und diese Meldungen erhalte ich höchst selten resp. immer direkt beim Edomi-Neustart.

Wie gesagt sind's bei mir 57% Peak, d.h. irgendwie hat mein uralter Atom scheinbar noch mehr Reserven...

Oder die Reserven sind ganz anderer Art und wir sind noch nicht drauf gekommen, was genau resp. welcher Art genau...

Gibt es eine Möglichkeit, den in Klammern dargestellten Peak-Wert zur Edomi-Laufzeit zurückzusetzen? Dann könnte man nachschauen, wie hoch der Peak nachts war.

Ich könnte mir also schon vorstellen, dass das Problem bei der Auslastung zu suchen ist: Irgendwas beschäftigt die CPU zu fast 100% und dann kann das offenbar recht sensible KNX-Gateway (EDOMI) nicht mehr zeitnah antworten.

Na die Hoffnung stirbt zuletzt, wir werden das schon noch rausfinden.

[gaert]

Ein Zurücksetzen ist aktuell nicht möglich, aber vielleicht kannst Du irgendein Tool bemühen, das die CPU-Last protokolliert.

[hx5]

aber vielleicht kannst Du irgendein Tool bemühen, das die CPU-Last protokolliert.

Äh, mit den Werks-LBS 18000100 + 18000110 sollte das doch ganz einfach sein oder übersehe ich da was?

[MuckiLegden]

Moin,

ich will meine Beobachtungen auch nochmal hier niederlegen.

Rahmenbedingungen:
- Edomi läuft in einer VM unter ESXI auf einem NUC i5.
- Ich habe an CentOS keinerlei Änderungen oder Updates vorgenommen mit einer Ausnahme: Bei Start des OS wird ein Pfad auf dem NAS gemountet, wo das Backup hinläuft.
- MDT IP-Schnittstelle

a.) Beim Edomi-Start geht die Prozessorlast auf ca. 80% (lt. Anzeige in Edomi), während des Backup's lt. ESXI "nur" auf ca. 40%.

b.) Ich hatte zu Spitzenzeiten ca. 13 Mio. Datensätze in ca. 350 Archiven bei einer Backupgröße von 2,5 GB. Ich habe hier einiges geändert (bzw. bin noch dran). Jetzt habe ich ca. 5 Mio. Datensätze in 285 Archiven und eine Backupgröße von ca. 650 MB. Die Häufigkeit der Fehler hat sich hierdurch nicht geändert!

c.) Ich habe in den letzten Tagen einige Archive angelegt, die mit mit dem System-KO "Trigger Täglich" Werte archivieren sollen. Dies funktioniert nicht zuverlässig. Ob das einen Zusammenhang mit dem Problem hat, kann ich nicht sagen.

Ohne Titel.jpeg
Hier fehlen die Einträge vom 21.07. und 23.07. Allerdings hatte ich an den Tagen keinen Disconnect-Request.

d.) Der Disconnect-Request tritt bei mir nicht ausschließlich um 0:00:xx auf! Selten auch mal mitten am Tag irgendwann (10.07. 22:58:25 & 23.06 08:41:26) habe ich im Fehlerlog gefunden.

Viele Grüße,
Mucki

[ggt]

... Dann könnte man nachschauen, wie hoch der Peak nachts war ...

Hallo Yves,

du kannst die Systemaktivitäten protokollieren. Dafür müsstest du sysstat installieren yum install sysstat
Die protokollierten Daten sollten sich dann im Verzeichnis /var/log/sa/ befinden und werden per default 1 Woche vorgehalten.

kurze Beschreibung: Linux_Performance_Aufzeichnung_und_Auswertung_mit_ sar

[gaert]

Also, um mal etwas Struktur reinzubringen...:

"Mitternacht" ist ja zunächst einfach nur ne Uhrzeit EDOMI macht aber um Mitternacht diverse Aufräumarbeiten (Logs löschen, etc.) - das sollte nicht weiter ins Gewicht fallen, da dies in einem eigenen Prozess im Hintergrund stattfindet und die DBs nicht weiter tangiert.

Das einzig besondere in diesem Kontext ist das automatische Backup, denn hier müssen nunmal aktuell DBs gelocked werden und offenbar braucht's auch einige Ressourcen. Daher wäre mein Vorschlag:

Schaltet das automatische Backup doch einfach mal ab! Dann ein paar Tage beobachten...

[Nanosonde]

Schaltet das automatische Backup doch einfach mal ab! Dann ein paar Tage beobachten...

Oder Ihr macht es nochmal so, wie ich es in diesem Posting gemacht habe:
https://knx-user-forum.de/forum/proj...04#post1058204

Automatisches Backup abschalten und dann versuchen, ob Ihr per manuellem Backup oder TAR den Fehler reproduzieren könnt. Das geht dann schneller.

Dieser Fehler (DISCONNECT) ist seit meinem Kernel-Update von 2.6 auf einen aktuellen Kernel damals komplett verschwunden. Sowohl beim NUC als auch der späteren HW (Deskmini 110 mit Celeron).

Schaut bei den Analysen nicht nur auf die reine CPU-Last, sondern auch darauf, ob irgendwo besonders viel I/O erzeugt wird.
Auffällig war bei mir, dass ein TAR ohne Kompression zu einem Problem führt, ein TAR mit Kompression und deutlich mehr CPU-Last zu keinem Problem.
Als Laufwerk wird nach wie vor eine Transcend SSD mit 32GB eingesetzt.

[MuckiLegden]

Moin,

ich habe das automatische Backup dann vorgestern mal abgeschaltet. Gestern kein Fehler, heute wohl wieder.


IMG_0152.PNG

Viele Grüße,
Mucki

P.S. Um 19.xx Uhr habe ich meine Wetterstation programmiert. (Und falls das interessiert: Die Programmierung erfolgte über einen IP-Router, Edomi ist über eine andere Schnittstelle angebunden)

[Simone]

Jetzt habe ich auch den Fehler.

2017-07-28 00:01:11616518KNX1561ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=255, Soll-Wert=0 / Raw: 0610042000170446ff002900bce0112024150300800000ERROR 

Ich habe seit der Version 1.51 nichts geändert. In den Logs sind mir 2 Lbsen mit ca. 1200 Fehlereinträgen Individual-Logs aufgefallen. Der eine schreibt schon seit Version 1.50 in die Logs da ich irgendwie die Eingänge falsch belegt habe und der andere ist eine Webabfrage die nicht mehr möglich ist (Unwetter LBS LBS19000156). Ich habe jetzt beide Logikseiten deaktiviert

[trollmar]

So. Kurzer Zwischenstand:
Das "ping -f" lief seit gestern die ganze Nacht durch. Es ist kein einziges Paket mehr verloren gegangen.
Auch Edomi hat um Mitternacht keinen SeqError produziert.




Hoffentlich war es das jetzt.

Achso. Getestet wurde das jetzt nicht mit dem MDT Interface, sondern mit der Kombi knxd/Merten USB Interface.
Und der Kernel wurde vor den ganzen Tests gestern auch noch aktualisiert:
Linux edomi 4.12.2-1.el6.elrepo.x86_64 #1 SMP Sat Jul 15 13:11:55 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

Es liegt nicht an der neuen Kernelversion, sondern an dem Parameter InterruptThrottleRate des e1000e Treibers.

Hi,
Gestern Nacht ab ca. 02:00 waren es hunderte disconnects ..das ging so bis 09:00

Nanosonde wie sieht es mittlerweile bei dir aus?
Wenn das bei dir nicht mehr auftritt muss ich auch mal nachdenken nicht mehr in ner Proxmox VM zu arbeiten.
Und mir dedizierte Hardware anschaffen.
LG

[hartmut]

Also bei mir läuft es auf einer Proxmox VM seit Anfang letzen Jahres.
Ich bekomme sehr selten diese disconnects ca. alle 14 Tage einen oder 2.
Die CPU Auslastung ist so um die 5% aber maximal auch (100). Das wird dann den disconect auslösen. Aber da es bei mir so selten ist stört es mich nicht.

[Nanosonde]

Nanosonde wie sieht es mittlerweile bei dir aus?

Also die Disconnects habe ich ja schon sehr lange nicht mehr. Bei mir half das Update des Kernels von der alten 2.6.x Version auf eine aktuelle Mainline Version.
Danach hatte ich immer mal die "normalen" SeqCounter Fehler.

Ich habe jetzt zum Testen mal wieder umgestellt von knxd/USB-IF auf das MDT-IF. Mal schauen was dort passiert.
Mit dem knxd/USB-IF hatte ich keine SeqCounter Fehler mehr (nach Deaktivierung des Interrupt-Throttlings, was ich ja besonders auf das Handling kleiner Pakete auswirkt). Jetzt werde ich das Ganze nochmal mit dem MDT-IF testen.

Allgemein:
Das Flood-Ping war aber schon ein guter Indikator.
Mittels manuellem TAR kann ich die Wahrscheinlichkeit für SeqCounter Fehler deutlich erhöhen, so dass ich sie quasi reproduzieren konnte.
Wenn diese auftraten, gingen auch Pakete beim Flood-Ping flöten.
Was mich nur immer noch wundert ist, dass nirgendwo in den Kernel-Statistiken ein "dropped packet" oder so auftaucht. Auch keine fehlerhaften Pakete.

Mal schauen...