FHEM Forum

FHEM => Sonstiges => Thema gestartet von: Prof. Dr. Peter Henning am 17 Mai 2020, 12:24:02

Titel: Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 17 Mai 2020, 12:24:02
Seit gestern (Update von FHEM durchgeführt) hängt sich meine Hauptinstallation reproduzierbar auf.

Nach einem Neustart ist zunächst alles Bestens, hohe Performance.

Nach ca. 1 Stunde beginnt die CPU-Last zu steigen (hellrote Kurve L90), gleichzeitig steigt die Temperatur des Mini-PC linear an (obere blaue Kurve T90). Der Seitenaufbau in FHEMWEB wird immer langsamer. Nach ca. 2-3 Stunden ist kein Seitenaufruf mehr möglich, der Browser wartet sich tot. Gleichzeitig sind 1-2 weitere FHEM-Prozesse im System zu sehen. Es kommt zu massiven timeouts bei angeblich nicht blockierenden Aufrufen aus dem Shelly-Modul heraus (siehe Log unten). Der in SYSMON angezeigte Netzwerktraffic steigt massiv an. Einzige Abhilfe bisher: Killen des FHEM-Prozesses.

Sieht man heute in der Grafik 2x: Kurz vor 6:00 und kurz nach 9:00.

Im Log eigentlich nichts großartig Auffälliges, bis auf eine ungewöhnliche und bisher nicht aufgetretene Häufung von Warnungen.

Auch ein freezemon liefert keine weitergehenden Erkenntnisse - berichtet nur, dass das Ding immer langsamer wird und damit auch Unterprogramme immer länger laufen. Auch kein Anstieg der Speichernutzung.

Ich tappe etwas im Dunkel, hat jemand eine Idee?

LG

pah


2020.05.17 10:28:39 1: Logfile gelöscht
2020.05.17 10:30:44 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 64029) line 1.
2020.05.17 10:31:04 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 64686) line 1.
2020.05.17 10:31:12 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 64831) line 1.
2020.05.17 10:31:38 1: [Shelly_Get] Error: wrong number of parameters
2020.05.17 10:35:00 1: [OSC] Device SZ.Roll.0: , shading => moving from position 85 towards 90
2020.05.17 10:35:02 1: [OSC] Device WZ.Roll.0: , shading => moving from position 85 towards 90
2020.05.17 10:35:54 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 70197) line 1.
2020.05.17 10:36:04 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 70239) line 1.
2020.05.17 10:36:19 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 70753) line 1.
2020.05.17 10:37:33 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 72133) line 1.
2020.05.17 10:40:23 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 10:40:57 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 76882) line 1.
2020.05.17 10:41:04 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 76974) line 1.
2020.05.17 10:41:18 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 77445) line 1.
2020.05.17 10:41:29 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 10:46:25 1: [Shelly_status]  has error connect to http://192.168.0.161:80 timed out
2020.05.17 10:46:25 1: [Shelly_status]  has error connect to http://192.168.0.162:80 timed out
2020.05.17 10:46:25 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 10:46:26 1: [Shelly_status]  has error connect to http://192.168.0.166:80 timed out
2020.05.17 10:46:26 1: [Shelly_status]  has error connect to http://192.168.0.164:80 timed out
2020.05.17 10:46:26 1: [Shelly_status]  has error connect to http://192.168.0.163:80 timed out
2020.05.17 10:46:26 1: [Shelly_status]  has error connect to http://192.168.0.165:80 timed out
2020.05.17 10:46:26 1: [Shelly_status]  has error connect to http://192.168.0.170:80 timed out
2020.05.17 10:46:29 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 86613) line 1.
2020.05.17 10:46:49 1: Timeout for SYSMON_blockingCall reached, terminated process 5318
2020.05.17 10:46:52 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 87423) line 1.
2020.05.17 10:47:00 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 87507) line 1.
2020.05.17 10:47:59 1: OWXTHERM_BinValues:  HK.Hz.RL: invalid CRC,  0  0x00 0x00 0xff 0xff 0x00 0x00 0xff 0xff 0x00
2020.05.17 10:48:28 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 89303) line 1.
2020.05.17 10:50:00 1: [OSC] Device SZ.Roll.0: , shading => moving from position 90 towards 95
2020.05.17 10:50:03 1: [OSC] Device WZ.Roll.0: , shading => moving from position 90 towards 95
2020.05.17 10:50:36 1: [Shelly_status]  has error connect to http://192.168.0.165:80 timed out
2020.05.17 10:50:36 1: [Shelly_status]  has error connect to http://192.168.0.163:80 timed out
2020.05.17 10:51:20 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 94030) line 1.
2020.05.17 10:51:29 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 94092) line 1.
2020.05.17 10:51:36 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 94108) line 1.
2020.05.17 10:52:41 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 95358) line 1.
2020.05.17 10:52:50 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 95360) line 1.
2020.05.17 10:54:23 1: 192.168.0.91:2323 disconnected, waiting to reappear (CUNO)
2020.05.17 10:54:23 1: 192.168.0.91:2323 reappeared (CUNO)
2020.05.17 10:56:17 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 100182) line 1.
2020.05.17 10:56:30 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 100641) line 1.
2020.05.17 10:56:37 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 100666) line 1.
2020.05.17 10:57:51 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 102393) line 1.
2020.05.17 10:58:38 1: [Shelly_meter has error connect to http://192.168.0.165:80 timed out
2020.05.17 10:58:49 1: [Shelly_meter has error write to http://192.168.0.166:80 timed out
2020.05.17 10:58:57 1: [Shelly_Set] Error: roller blind still moving, wait for some time
2020.05.17 10:59:06 1: [Shelly_status]  has error write to http://192.168.0.177:80 timed out
2020.05.17 10:59:57 1: OWXSWITCH_BinValues ds2406.getstate.final: USV.Status: invalid CRC in getstate, 0xff 0xff 0xff 0xff
2020.05.17 11:00:00 1: [OSC] Device SZ.Roll.0: , shading => moving from position 85 towards 95
2020.05.17 11:01:22 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 107779) line 1.
2020.05.17 11:01:36 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 108548) line 1.
2020.05.17 11:01:36 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 11:01:48 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 108838) line 1.
2020.05.17 11:03:07 1: [Shelly_status]  has error write to http://192.168.0.167:80 timed out
2020.05.17 11:03:31 1: [Shelly_status]  has error write to http://192.168.0.161:80 timed out
2020.05.17 11:03:31 1: [Shelly_status]  has error write to http://192.168.0.177:80 timed out
2020.05.17 11:03:32 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 111902) line 1.
2020.05.17 11:03:38 1: [Shelly_status]  has error read from http://192.168.0.164:80 timed out
2020.05.17 11:03:38 1: [Shelly_status]  has error write to http://192.168.0.166:80 timed out
2020.05.17 11:06:29 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 116159) line 1.
2020.05.17 11:06:39 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 116394) line 1.
2020.05.17 11:06:46 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 116610) line 1.
2020.05.17 11:07:58 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 118256) line 1.
2020.05.17 11:08:05 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 118290) line 1.
2020.05.17 11:09:11 1: [OSC] Device SZ.Roll.2: has received event open from sensor SZ.Tuer.K
2020.05.17 11:09:32 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 121188) line 1.
2020.05.17 11:09:37 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 121460) line 1.
2020.05.17 11:09:40 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 121476) line 1.
2020.05.17 11:10:01 1: [OSC] Device AZ.Roll.G: , shading => moving from position 30 towards 20
2020.05.17 11:10:01 1: [OSC] Device SZ.Roll.0: , shading => moving from position 95 towards 60
2020.05.17 11:10:05 1: [OSC] Device WZ.Roll.0: , shading => moving from position 95 towards 60
2020.05.17 11:10:15 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 122464) line 1.
2020.05.17 11:10:51 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 11:10:51 1: [Shelly_status]  has error connect to http://192.168.0.161:80 timed out
2020.05.17 11:11:30 1: OWXSWITCH_BinValues ds2406.getstate.final: USV.Status: invalid CRC in getstate, 0xff 0xff 0xff 0xff
2020.05.17 11:11:37 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 125268) line 1.
2020.05.17 11:11:39 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 125273) line 1.
2020.05.17 11:11:44 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 125298) line 1.
2020.05.17 11:13:31 1: [Shelly_status]  has error write to http://192.168.0.166:80 timed out
2020.05.17 11:13:31 1: [Shelly_status]  has error write to http://192.168.0.165:80 timed out
2020.05.17 11:13:31 1: [Shelly_status]  has error write to http://192.168.0.162:80 timed out
2020.05.17 11:13:42 1: [DoorPi_Cmd] called with only hash and cmd=button1 => Issue a non-blocking call to http://192.168.0.190:80/control/trigger_event?event_name=OnKeyPressed_webservice.button1&event_source=doorpi.keyboard.from_filesystem
2020.05.17 11:13:44 1: [Shelly_status]  has error read from http://192.168.0.170:80 timed out
2020.05.17 11:13:44 1: [Shelly_status]  has error read from http://192.168.0.163:80 timed out
2020.05.17 11:15:00 1: OWXMULTI_BinValues:  USV.Capacity: VAD not different from VDD
2020.05.17 11:16:39 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 133367) line 1.
2020.05.17 11:16:55 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 133908) line 1.
2020.05.17 11:16:55 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 133910) line 1.
2020.05.17 11:19:29 1: OWXSWITCH_BinValues ds2406.getstate.final: HK.WW.Pumpe.St: invalid CRC in getstate, 0x4b 0x46 0x7f 0xff
2020.05.17 11:19:34 1: [Shelly_status]  has error write to http://192.168.0.161:80 timed out
2020.05.17 11:19:34 1: [Shelly_status]  has error write to http://192.168.0.163:80 timed out
2020.05.17 11:19:35 1: [Shelly_status]  has error write to http://192.168.0.170:80 timed out
2020.05.17 11:19:35 1: [Shelly_status]  has error write to http://192.168.0.167:80 timed out
2020.05.17 11:21:45 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 142227) line 1.
2020.05.17 11:21:48 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 142237) line 1.
2020.05.17 11:22:01 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 142753) line 1.
2020.05.17 11:26:51 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 151767) line 1.
2020.05.17 11:27:41 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 153729) line 1.
2020.05.17 11:27:41 1: [Shelly_status]  has error write to http://192.168.0.163:80 timed out
2020.05.17 11:27:51 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 154043) line 1.
2020.05.17 11:30:52 1: [Shelly_status]  has error connect to http://192.168.0.162:80 timed out
2020.05.17 11:30:52 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 11:30:53 1: [Shelly_status]  has error connect to http://192.168.0.170:80 timed out
2020.05.17 11:30:53 1: [Shelly_status]  has error connect to http://192.168.0.164:80 timed out
2020.05.17 11:30:53 1: [Shelly_status]  has error connect to http://192.168.0.165:80 timed out
2020.05.17 11:30:53 1: [Shelly_status]  has error connect to http://192.168.0.166:80 timed out
2020.05.17 11:30:54 1: [Shelly_status]  has error connect to http://192.168.0.161:80 timed out
2020.05.17 11:30:54 1: [Shelly_status]  has error connect to http://192.168.0.163:80 timed out
2020.05.17 11:32:35 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 164510) line 1.
2020.05.17 11:33:02 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 165438) line 1.
2020.05.17 11:33:45 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 167034) line 1.
2020.05.17 11:37:22 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 174725) line 1.
2020.05.17 11:37:35 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 174754) line 1.
2020.05.17 11:39:43 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 181498) line 1.
2020.05.17 11:40:22 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 7652
2020.05.17 11:40:22 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.05.17 11:40:26 1: [Shelly_status]  has error connect to http://192.168.0.161:80 timed out
2020.05.17 11:40:26 1: [Shelly_status]  has error connect to http://192.168.0.167:80 timed out
2020.05.17 11:40:26 1: [Shelly_status]  has error connect to http://192.168.0.164:80 timed out
2020.05.17 11:40:26 1: [Shelly_status]  has error connect to http://192.168.0.163:80 timed out
2020.05.17 11:40:27 1: [Shelly_status]  has error connect to http://192.168.0.165:80 timed out
2020.05.17 11:40:35 1: Timeout for SYSMON_blockingCall reached, terminated process 7663
2020.05.17 11:43:15 1: KLF200 (VeluxIO) - connectionBroken -> closed connection
2020.05.17 11:43:15 1: KLF200 (VeluxIO) - connectionBroken -> reopen connection in 5 seconds
2020.05.17 11:43:25 1: [Shelly_status]  has error write to http://192.168.0.177:80 timed out
2020.05.17 11:43:32 1: Timeout for SYSMON_blockingCall reached, terminated process 7691
2020.05.17 11:43:42 1: [Shelly_status]  has error write to http://192.168.0.162:80 timed out
2020.05.17 11:43:42 1: [Shelly_status]  has error write to http://192.168.0.170:80 timed out
2020.05.17 11:43:42 1: [Shelly_status]  has error write to http://192.168.0.166:80 timed out
2020.05.17 11:43:46 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 192735) line 1.
2020.05.17 11:49:51 1: [Shelly_status]  has error write to http://192.168.0.163:80 timed out
2020.05.17 11:50:12 1: Timeout for SYSMON_blockingCall reached, terminated process 7854
2020.05.17 11:50:15 1: [Shelly_status]  has error write to http://192.168.0.164:80 timed out
2020.05.17 11:50:15 1: [Shelly_status]  has error write to http://192.168.0.161:80 timed out
2020.05.17 11:50:15 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 7903
2020.05.17 11:50:16 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.05.17 11:50:27 1: [Shelly_status]  has error write to http://192.168.0.165:80 timed out
2020.05.17 11:50:27 1: [Shelly_status]  has error write to http://192.168.0.167:80 timed out
2020.05.17 11:50:46 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 213780) line 1.
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: KölnSolar am 17 Mai 2020, 12:44:34
ZitatIch tappe etwas im Dunkel
Versteh ich. Sieht irgendwie nach generellem Problem mit der Peripherie aus. Kein Netzwerk oder wenig /selten ?  :-\ Noch nicht einmal die Netzwerk/System-blockingCalls  laufen durch.
Mehr fällt mir grad auch nicht ein. :-[

Edit: nix im Systemlog, (ich las doch eben noch Mini-PC ???) Bei Linux: keine Meldungen bei dmesg ?
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 17 Mai 2020, 13:01:23
Das Netzwerk habe ich in den vergangenen Tagen ziemlich umgestrickt - 2 neue GBit-Switches hineingebaut.

Zumindest die Quelle der Warnungen habe ich jetzt gefunden: Ein uraltes DOIF im Raum hidden, dessen Device längst nicht mehr existierte.

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: KölnSolar am 17 Mai 2020, 13:08:58
besser mal in die Hardware-Ecke verschieben ?
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: herrmannj am 17 Mai 2020, 13:11:05
Ohne strukturierte Analyse in der Tat schwer zu finden. Potentielle Quellen gehen gegen unendlich.

Ich würde damit beginnen in der select loop (fhem.pl) debug lines einzufügen und auf Auffälligkeiten zu achten. Möglicherweise direkt hinter dem select. Zweite Quelle möglicherweise Timer, mit analogem Vorgehen (debug lines)
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 17 Mai 2020, 14:05:33
ZitatPotentielle Quellen gehen gegen unendlich.

So isses.

Nächster Verdacht: Kabel zwischen den beiden Switches - aber der Managed Switch behauptet, es sei alles ok.

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Wernieman am 17 Mai 2020, 14:24:27
Aber dann würde nicht nur FHEM meckern ...

Aber wenn Du was am Netzwerk "gebastelt" hast, was sagen die "Fehler" in der Netzwerkkarte?
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Otto123 am 17 Mai 2020, 14:35:28
Hi,

mal Netzwerk wieder "einfacher" stricken?
Klingt mir danach als ob fhem irgendwas macht, was anschließend irgendwelche Races in den neuen Switches auslöst. Durch die Überlastung kann FHEM seine Netzwerkpunkte nicht mehr erreichen und läuft in Fehler?
Steigt denn mit der Temperatur im Mini-PC der Traffic in den Switches?

Gruß Otto
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: rudolfkoenig am 17 Mai 2020, 17:32:08
Wenn mir nichts besseres/einfacheres mehr einfaellt, dann schaue ich die Ausgabe von strace an.
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 17 Mai 2020, 19:51:48
Mysteriös, und wirklich reproduzierbar. Verkabelung OK, Switches melden keine Fehler.

Ich habe jetzt mal spaßeshalb den LAN-Anschluss totgelegt und die IP-Adresse dem WLAN-Adapter des Mini-PC zugewiesen.

System läuft erstmal wieder, danke für Eure Denkanstöße.

An der Grafik sieht man sehr schön den Zyklus, den ich jedesmal durch einen Neustart von FHEM oder gar einen kompletten Reboot beenden musste. Ab 17:30 (da waren wir noch auf einer kleinen Runde Golf) gibt es dann nicht einmal mehr Daten (das Logging und die Grafik werden auf einer anderen FHEM-Instanz gemacht).

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 18 Mai 2020, 04:31:31
Denkste. Dauert nur länger mit WLAN.

Der Output von strace deutet tatsächlich auf ein Problem hin, ich verstehe es aber noch nicht - massiver Strom von Zeilen der Form

Zitatstat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0

Mal sehen, was habe ich gemacht, bevor die Misere begann...

Ein paar Devices gelöscht. Dabei eines zuviel. Gut, also habe ich mir gedacht mit
configdb recover 1
kann ich die Konfiguration wieder herstellen. Daraufhin natürlich eine Warnung, ich müsse mit
rereadcfg
die restaurierte Konfiguration einlesen. Gut, gemacht. Massen an Fehlermeldungen, also FHEM gekillt und neu gestartet.

Offenbar habe ich dabei auch die fhem.save zerschossen, jedenfalls waren einige Werte nach dem Neustart nicht initialisiert.

Alles kein Problem, die habe ich manuell bzw. durch Abfrage der Devices wieder geholt.

Und seitdem ist das System in diesem Zustand...

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Gisbert am 18 Mai 2020, 07:27:18
Hallo pah,

ich hatte vor ein paar Monaten ein ähnliches, selbst verursachtes Problem. Ich hatte eine Definition durch Kopieren in fhem.cfg überschrieben und dabei zunächst übersehen, dass eine längere Zeile abgeschnitten kopiert wurde. Ich weiß, dass Editieren der fhem.cfg sich nicht gehört, deshalb hab ich erst gar nicht versucht im Forum Hilfe zu finden. Ich oute mich damit gewissermaßen, aber da das anschließende Verhalten deinem Problem ähnlich ist, wollte ich es schildern.

Fhem lief zwar, aber wie ein Sack Muscheln. Jedenfalls war das Verhalten so, dass ein Seitenaufbau beim Aufruf im Browser extrem zäh war, Faktor 10 hat nicht gereicht, eher so 20, 30mal langsamer, es machte sich eine gewisse Panik breit. Der Fehler war schnell lokalisiert, da ich ja wusste, was ich kurz vorher gemacht gatte. Bis ich gesehen hatte, dass die Definition in einer Zeile (am Bildschirmrand) abgeschnitten war, hat es etwas gedauert.

Viele​ Grüße​ Gisbert​
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 18 Mai 2020, 07:55:52
So etwas mache ich nicht - darum ja recover der configdb.

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: rudolfkoenig am 18 Mai 2020, 09:11:38
Zitatstat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
Da ruft jemand wiederholt localtime() auf, in fhem.pl waeren Kandidaten dafuer alle benutzerdefinierte perl Ausdruecke (ausgenommen userReadings), oder IsDisabled (falls disabledForIntervals gesetzt ist).

Interessant waere es die Syscalls vor/nach stat(/etc/localtime) zu sehen, um den Verursacher zu lokalisieren.
Ich wuerde versuchen "attr global verbose 5" zu setzen.
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 18 Mai 2020, 13:49:17
Mysteriöser und mysteriöser.

Im ersten Bild der komplette Graph von gestern. Nach der Umstellung auf WLAN um kurz vor 19:00 fällt die Temperatur auf knapp unter 40 °C, alles prima - bis um ca. 21:30 das Spiel von Neuem beginnt. Ab Mitternacht dann etwa war das System wieder komplett blockiert.

Heute morgen um 4:30 habe ich das System dann noch einmal neu gestartet - und ich schwöre beim Grab meiner Schwiegermutter, ich habe nichts weiter geändert. Wie man am zweiten Bild sieht, ist die Temperatur danach wieder gefallen und, man staune, nahezu konstant seitdem. Ab und zu höherer Load, das wars dann aber auch - nicht mehr dieser Anstieg mit der Zeit.


LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Gisbert am 18 Mai 2020, 18:33:29
Hallo pah,

tja, wenn Software im Spiel ist kann alles passieren.
Zitatund ich schwöre beim Grab meiner Schwiegermutter
Gerne wird auch die Geschichte von der Hand ins Feuer legen bemüht, obwohl seine Hand ins Feuer zu legen, kann niemals eine gute Idee sein ;D
Ansonsten hilft manchmal Fluchen, Beten, Androhung von Gewalt (gegenüber der bockigen Hardware) ... ;D :-X

Viele Grüße​ Gisbert​
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Icinger am 18 Mai 2020, 18:35:45
ZitatAndrohung von Gewalt (gegenüber der bockigen Hardware)
Deshalb steht neben meinem Server ein Vorschlaghammer  :P :P
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Wernieman am 18 Mai 2020, 18:50:17
Bei meinem Job "damals" in München war das erste Werkzeug, welches ich für die Systemadministration bestellen sollte, ein Hammer ...
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 18 Mai 2020, 20:17:22
Ich glaube stattdessen an die Selbstheilungskräfte von Maschinen.

LG

pah
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: enno am 18 Mai 2020, 20:48:11
Zitat von: Prof. Dr. Peter Henning am 18 Mai 2020, 20:17:22
Ich glaube stattdessen an die Selbstheilungskräfte von Maschinen.

Ich sehe du kommst meiner Bitte nach KI (für FHEM) immer näher ;D

Gruss
  Enno
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: xenos1984 am 18 Mai 2020, 21:58:37
Um dem Netzwerk auf die Spur zu kommen, würde ich es wohl mit WireShark versuchen, und schauen, ob da irgendwo Pakete verloren gehen - falls es denn wirklich mit der Kommunikation zusammenhängen sollte.
Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: Prof. Dr. Peter Henning am 19 Mai 2020, 15:39:47
Der gemanagte Switch hat behauptet, dass es keinerlei fehlerhafte Pakete gegeben habe.

Und seit dem letzten Reboot gestern früh um 4:30 läuft das System ohne irgendeine Änderung an der Konfiguration wieder vollkommen stabil, mit konstanter Temperatur und Last. Irre - so kann ich nicht einmal mehr herausfinden, woran es denn lag.


@Enno: Habe ich doch schon... Also, Off-Topic:

Das Modul Babble stellt eine regelbasierte KI für die Spracherkennung dar, mit der Ankopplung an einen Rivescript-Chatbot sind echte Unterhaltungen mit dem Haus möglich. Spaßeshalber habe ich inzwischen auch eine Deep-Learning KI ausprobiert, nämlich die Spracherkennung mit Rasa. Flexibilisiert die Spracherkennung (genauer: Die Erkennung eines Intents) noch weiter, bringt aber nicht wirklich einen Mehrwert. Zum Thema Verhaltenserkennung habe ich schon zwei Abschlussarbeiten schreiben lassen, beide mit dem Resultat, dass auch hier ein regelbasiertes System besser ist.

Beispiel: Wenn ich den Wasserverbrauch regelbasiert überwache, kann ich problemlos einstellen, dass fehlender Wasserverbrauch über mehr als 4 Stunden auf eine hilflose Person im Haus hinweist. Wenn ich die Wasserverbrauchsmesswerte mit einem neuronalen Netz überwache, lernt das Netz nur, dass mit hoher Wahrscheinlichkeit der nächste Messwert wieder Null sein wird.

LG

pah

Titel: Antw:Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: rabehd am 19 Mai 2020, 15:48:42
Zitat von: Wernieman am 18 Mai 2020, 18:50:17
Bei meinem Job "damals" in München war das erste Werkzeug, welches ich für die Systemadministration bestellen sollte, ein Hammer ...

Ich kenne noch eine Rechenanlage auf Basis von Röhrentechnik. Da wurde ein Fehler erst im zweiten Schritt gesucht. Der erste Schritt war Einschub (für Jüngere: Platine) rausziehen und mit Schwung wieder rein. Oft war der Fehler weg und keine Suche notwendig.
Titel: Brainstorming: FHEM mit linear ansteigender Last bis zur Blockade
Beitrag von: KernSani am 19 Mai 2020, 16:39:41
Nach mehreren Jahrzehnten in der IT bin ich fest davon überzeugt, dass in Microchips kleine Kobolde die Arbeit verrichten und gelegentlich haben die halt keine Lust oder  sind rebellisch drauf. ;-)


Kurz, weil mobil....