FBAHA: Resetting Buffer .... ?

[grappa24]

Kann jemand diese Fehlermeldung erklären? Letzlich führt es dazu, dass mein FHEM sehr langsam reagiert bzw. eine zeitlang nicht erreichbar ist ...

[rudolfkoenig]

Dem FHEM FBAHA Modul kommen die Laengenangaben in den Nachrichten der FritzBox AHA Server komisch vor, Laengen < 16 oder > 10240 werden mit dieser Meldung abgewiesen.  Bei der oberen Grenze habe ich vielleicht zu kurz gedacht, die untere finde ich aber nach wie vor valide.

[rudolfkoenig]

Ich habe die Obergrenze auf 20k gesetzt.
Es wuerde mich interessieren, ob das Problem nach einem FHEM-Restart oder nach einem FritzBox-Restart weiter besteht.
Es waere auch interessant die Ausgabe von top zu sehen, wenn das System langsam ist.

[grappa24]

Danke!   ... ich spiele es gerade ein und werde berichten
VG, Dieter

[grappa24]

hat leider nix gebracht, update eingespielt, FBF neu gestartet ... eben trat der Fehler wieder auf: FHEM ist dann nicht erreichbar, erst nach ein paar Minuten gehts dann wieder ...

[rudolfkoenig]

> update eingespielt

glaube ich nicht, dein screenshot zeigt was von 12428 bytes an, und die aktuelle grenze ist 20480.
Bei den anderen Zeilen wird dieser update nichts bewirken, weil ich nicht weiss, was da falsch ist.
Mein FB liefert die Daten seit Monaten ohne eine einzige solche Meldung.

Wenn ich helfen soll, dann bitte _ALLE_ meine Fragen beantworten:
- wieviele/welche DECT Geraete hast du angeschlossen
- welcher FB Typ (7390/etc) wird abgezapft, bzw. wo laeuft FHEM
- welcher OS Version ist auf dem FB installiert
- kommt das Problem mit dem letzten FB-OS-Labor Update auch vor
- wenn das Problem vorkommt, was steht in top (screenshot)
- verwendest Du zum anzeigen/prufen der DECT Geraete ausser FHEM noch was anderes? (FB-Oberflaeche/Telefon/etc)

[grappa24]

Meine Konfiguartion sah zum Zeitpunkt der Fehlermeldung wie folgt aus:
- erste   FBF 7390 mit OS 6.00, FHEM 5.5 und einem DECT200
- zweite FBF 7390 mit OS 5.52, FHEM 5.5 und einem weiteren DECT200
- auf der ersten FBF laufen meine Floorpläne
- die zweite FBF ist via FHEM2FHEM (im LOG-Modus) mit der ersten verbunden
- siehe dazu auch http://forum.fhem.de/index.php/topic,14902.msg106301.html#msg106301
- Zum Gegencheck greife ich auf die DECT200 auch von Zeit zu Zeit über die Oberfläche der Fritz!Boxen zu

Ich habe letzte Woche auf OS 6.0 und FHEM 5.5 umgestellt und meine FHEM-Installation von einer früheren OS Version übertragen. Bei der Fehlersuche ist mir aufgefallen, dass AVM bei OS 6.0 bei den DECT-Adapertern auch viel umgestellt hat; so wird jetzt ein DECT-Device, was an einer IP-Client-FBF angeschlossen ist, auch in der Weboberfläche der Hauptbox angezeigt und kann gesteuert werden, was mit OS 5.52 bzw. meiner Labor 05.55-25409 nicht ging.

Ich hab jetzt nochmal alle DECT Devices gelöscht, den FHEM2FHEM (LOG) entfernt und dann neu angelegt und siehe da: Die FBDECT Events werden von der IP-Client-Box auch ohne FHEM2FHEM auf die Hauptbox übertragen. Und vor allem lässt sich auch das Device der IP-Client-Box über den Floorplan auf der Hauptbox schalten, was vorher nur umständlich mit einem dummy und einem notfifier ging ...

Bis jetzt sind die Buffer Probleme nicht mehr aufgetreten, mal sehen ....

Läuft immer noch stabil ohne die o.a. Fehlermeldungen und die Box "schläft" auch nicht mehr ein ....

[grappa24]

irgendwas scheint da aber immer noch nicht zu stimmen (Anlage). Seit der Fehlermeldung um 00:30:47 hat die Hauptbox dann keine FBDECT Messages mehr bekommen ...

Rudolf, was genau meinst Du hiermit: "wenn das Problem vorkommt, was steht in top (screenshot)"

[rudolfkoenig]

Via telnet anmelden, top starten.

[grappa24]

hier der screenshot zu top:

[rudolfkoenig]

Da ist nichts zu sehen, das System ist unauffaellig (93% idle, fhem belegt 0%) . top braucht man, falls FHEM traege reagiert, um zu sehen ob FHEM selber CPU Zyklen verschwendet, oder jemand anderes (AHA daemon, etc).
Ich vermute aber, dass dieses Problem (FHEM ist traege) nicht mehr aktuell ist.

[grappa24]

gut, zu dem Zeitpunkt des screenshot lief das System glatt.

Ich verstehe, ziehe also ein Prozessabbild, wenn das System das nächste mal wieder hängt.

Wenn ich ja nicht so an den FRITZ!Boxen hängen würde, hätte ich mir schon längst einen RasPi besorgt .....   

[Puschel74]

Hallo,

siehe meine Sig. 

Grüsse

[grappa24]

@Puschel: Ja ja ...

Aber ich krieg das schon hin, ich kümmere mich jetzt mal um das Speichermanagement meiner FBF, ich denke, durch das Laden von langen Log-Dateien müllt mir auch der Speicher zu. Nach einem Kaltstart der Box rennt das FHEM-System immer wie neu ...

Werd jetzt mal überflüssige Logs entfernen, der Tip mit "top" von Rudolf war gut ...

[Mani007]

Ist das Problem jetzt eigentlich schon gefunden worden oder nicht ??

Mich hats jetzt nämlich auch erwischt . Grins

Angefangen hat das ganze ab dem Zeitpunkt wo ich des 2. DECT Modul intergriert habe !!
Habe sogar Rekordwerte höher als 20K.

FBAHA: resetting buffer as we are out of sync (78294)

Die Plots werden nicht mehr geschrieben und fhem is nicht mehr erreichbar bis zu 1 1/2 Stunden.
Ich habe top in eine log mit timestamp schreiben lassen um es besser nach zu vollziehen .

Auch eine verbose 5 zeigt nichts mehr dann an so ne halbe std lang und dann kommen die Meldungen fbaha: resetting buffer.
Ein Neustart von fhem oder der Fritzbox bringt nur vorübergehend etwas .

Auch der Syslog Eintrag zeigt 100 % load an:

Code Auswählen Erweitern

Dec 29 03:09:00 fritz kern.warn kernel: system-load 1 curr: perl runnable: 2
Dec 29 05:18:02 fritz kern.warn kernel: system-load 1 curr: perl runnable: 2
Dec 29 05:18:13 fritz kern.warn kernel: system-load 8 curr: perl runnable: 1
Dec 29 05:18:24 fritz kern.warn kernel: system-load 100 % curr: perl runnable: 1
Dec 29 05:18:34 fritz kern.warn kernel: system-load 9 curr: perl runnable: 1

Der top Auszug ist leider nicht zum gleichen Zeitpunkt wie der von Fhem muss ich erst wieder warten bis das Problem auftritt.
Vielleicht kann man ja was tun ?

[grappa24]

tritt bei mir sporadisch auch immer noch auf (zuletzt 24.12. und 20.12.) mit 66.000 - 68.000 legt aber mein System nicht mehr lahm

[Mani007]

Hallo grappa24,

hast du wie beschrieben aufgeräumt oder was hast du gemacht

[grappa24]

ich achte jetzt schon drauf, dass ich keine unnötigen LOG-Dateien mitschleppe und lösche auch das Logfile regelmäßig. Ich hab mal gelesen, dass das Logfile beim Ansehen in den Speicher geladen wird und da verbleibt; wenn ich das öfter mache, kann ich meine FBF reproduzierbar lahmlegen ... 

Dann habe ich ein delConn (+*01:00 delete FHEMWEB:.*) eingebaut, da ich mit verschiedenen Devices (tablet, smartphone, PC, ...) auf FHEM zugreife und die vielen FHEM Instanzen auch Speicher fressen ...

Wenn ich auf häufige Logfile Aufrufe verzichte und meine FBF "machen" lasse, dann läuft sie heute zuverlässig ...

VG, Dieter

[Mani007]

Hab ein bisschen reduziert jetzt sind die werte nicht mehr so hoch, aber was mir aufgefallen ist beim backup machen danach krieg ich immer noch kurz mal resetting buffer.