Neues Modul: 98_FREEZEMON Freezes monitoren und Verursacher identifizieren

[rudolfkoenig]

Non blocking SSL Connect würde aber eigentlich gehen

Theoretisch schon (geek hat vor 5 Jahren fuer Nonblocking Write in FHEMWEB einen Patch gebaut, was SSL explizit beruecksichtigt), aber ich meine unser SSL-accept ist immer noch blocking, da $clientinfo[0]->blocking(0) auf manchen Systemen Probleme verursachte.

Kennt jemand eine Methode, wie ich das Problem reproduzieren kann, zwecks nonblocking-ssl-connect Einbau?

[KölnSolar]

Wenn ich Joachims und meine Beobachtungen zusammenpacke, hilft sicherlich eine schlechte bzw. viel genutzt WLAN-Verbindung und häufige https-requests, um das Problem zu reproduzieren.

Wenn Du mir Codeschnipsel schickst, kann ich hier in meiner Umgebung gerne testen, wenn Du darin einen gangbaren Weg siehst.

[MadMax-FHEM]

Wenn ich Joachims und meine Beobachtungen zusammenpacke, hilft sicherlich eine schlechte bzw. viel genutzt WLAN-Verbindung und häufige https-requests, um das Problem zu reproduzieren.

Wenn Du mir Codeschnipsel schickst, kann ich hier in meiner Umgebung gerne testen, wenn Du darin einen gangbaren Weg siehst.

Für Tests schließe ich mich an...

Wenn es noch Sinn macht, dann baue ich auch mal um auf LAN etc.

Allerdings erst morgen oder am Mo...

Gruß, Joachim

[rudolfkoenig]

Danke fuer die Angebote, aber ich muss das schon selbst testen.
Blockieren muss es bei der SSL-Handshake, nicht davor, und nicht danach.

[herrmannj]

Gedankenspiel. Simulieren durch einen Server dessen Bandbreite künstlich begrenzt ist, zb auf 10byte/ Sekunde. Kann das ein weg sein?

[KölnSolar]

Ich wuerde versuchen mehrere Request ueber die gleiche Verbindung abzusetzen

Für "Nina"" hab ich das schon einmal umgesetzt. Scheint zu funktionieren. Nur noch 1 DNS-Aufruf/Zyklus(folglich auch nur 1 TLS-handshake). Somit um 80% traffic reduziert. 
Ich frag mich nur, warum ohne das keepalive nicht bereits vorher nur einmal die DNS-Abfrage erfolgte und die weiteren 4 vom FHEM-DNS-Cache "beantwortet" wurden.  Die Antwort sah so aus

Code Auswählen Erweitern

2020.01.19 11:54:37 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: nginx
Cache-Control: max-age=2
Content-Type: application/json
Strict-Transport-Security: max-age=31536000; includeSubdomains;
Date: Sun, 19 Jan 2020 10:54:37 GMT
Expires: Sun, 19 Jan 2020 10:54:39 GMT
X-Xss-Protection: 1; mode=block;
ETag: "5e1c93d7-2"
X-Content-Type-Options: nosniff;
Connection: close
Last-Modified: Mon, 13 Jan 2020 15:59:19 GMT
X-Frame-Options: SAMEORIGIN
Content-Length: 2

Schönen Restsonntag
Markus

[rudolfkoenig]

Ich frag mich nur, warum ohne das keepalive nicht bereits vorher nur einmal die DNS-Abfrage erfolgte und die weiteren 4 vom FHEM-DNS-Cache "beantwortet" wurden.

Kannst du das mit einem Log belegen?
Ich brauche etwas mit "attr global verbose 5", wo man auch "DNS result for..." Zeilen sieht, mit ttl.

[KölnSolar]

mit verbose 5 (auch global) sehe ich weder DNS query, answer, result noch IP. kein einziges mal. Bei anderen Modulen sehe ich die.
Ich sehe nur 5 requests in meinem pi-hole.
Vielleicht zur Info: blockingcall mit 5 blockingget auf die selbe Domain.

[rudolfkoenig]

Sorry, habs vergessen zu sagen:
- "IP: name -> a.b.c.d" sieht man nur bei Http_NonblockingGet, falls verbose ueber $hash->{loglevel} (Voreinstellung ist 4)
- "DNS*" Meldungen nur bei gesetzten dnsServer Attribut, falls die Adressen nicht aus dem Cache (siehe ttl) beantwortet werden, global verbose 4/5

[KölnSolar]

Hmm,
IP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen  von DNS*

[KernSani]

Hmm,
IP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen  von DNS*

Du kannst auch einfach mal mit einem

Code Auswählen Erweitern

{HttpUtils_dumpDnsCache()}
checken, was im DNS Cache steht

[KernSani]

Liebe Freeze-Freaks,

zwei Dinge:
1. Ich habe ein weiteres Attribut fm_catchHttp gebastelt, das versucht lang laufende Callback-Funktionen zu erkennen, als weiteren Schritt, "bad guys" zu identifizieren. Die Version läuft in meinem Produktivsystem und wenn sie bis morgen abend durchläuft ohne das System zu töten, würde ich sie morgen hier zum Test bereitstellen
2. Die Analyse von Freezes bzw. den Verursachern ist immernoch eklig und erfordert eine gewisse Erfahrung. Das würde ich gerne für den normalen Anwender vereinfachen. Mir schwebt eine "Analyze"-Funktion vor, die dem Anwender genauere Hinweise gibt, wo er mal schauen sollte und was er getrost ignorieren kann. Es gibt so ein paar Kandidaten, die permanent laufen (im Sekundentakt) und daher immer, oder sehr häufig als potentielle Freeze-Verursacher auftauchen, bei mir sind das aktuell:

Code Auswählen Erweitern


HMLAN_KeepAliveCheck,HMLAN_KeepAlive,RESIDENTStk_DurationTimer,PRESENCE_StartLocalScan,MQTT2_SERVER_keepaliveChecker
   
Mich würde interessieren, welche weiteren von diesen "immer da" Prozessen ihr habt (also, was ihr in fm_whitelistSub eingetragen habt)

Danke,

Grüße,

Oli

[rudolfkoenig]

IP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen  von DNS*

Die HttpUtils eigene, nicht blockierende DNS-Aufloesung wird nur bei NonblockingGet aufgerufen: fuer BlockingGet sehe ich den Sinn nicht, und es waere aufwendig zu implementieren.

[KölnSolar]

fuer BlockingGet sehe ich den Sinn nicht, und es waere aufwendig zu implementieren.

ich auch nicht. 

Die HttpUtils eigene, nicht blockierende DNS-Aufloesung wird nur bei NonblockingGet aufgerufen

diese klare Info fehlte halt nur. Also alles gut.

Mich würde interessieren, welche weiteren von diesen "immer da" Prozessen ihr habt (also, was ihr in fm_whitelistSub eingetragen habt)

Nichts. Und ich bin aktuell runter auf threshold=0,3 

Die Version läuft in meinem Produktivsystem und wenn sie bis morgen abend durchläuft ohne das System zu töten, würde ich sie morgen hier zum Test bereitstellen

Gerne auch vorher. Ich bin da auch nicht so ängstlich mit meinem Produktivsystem und heute bleibe ich "daneben" sitzen. 

[KernSani]

So, here we go, neue Version zum Testen.

* neues Attribut fm_catchHttp: echt hässliches Ding, aber scheint zu funktionieren... biegt beim Aufruf von HttpUtils_nonBlockingGet die callback-Funktion auf Freezemon um, Freezemon nimmt die Zeit und ruft dann die Originalfunktion auf
* altes Attribut fm_logExtraSeconds: wieder reaktiviert, erlaubt es zusätzliche Sekunden vor dem Freeze zu loggen
* Kleinkram

shutdown restart benötigt, reload reicht nicht (und rereadcfg traue ich nicht)