Hallo, vor ein paar Tagen habe ich ein FHEM UPDATE durchgeführt. Seitdem wird das System nach einiger Zeit immer langsamer. Wenn ich bspw einem Arduino Anschluss sage , dass er für 0,5sec einschalten soll, dauert es irgendwann dann 3sec. Zeitgesteuerte Events bleiben auch hängen. An meiner FHEM.cfg hat sich nichts geändert. Ein Neustart des PCs löst das Problem mal wieder für ein paar Minuten oder Stunden. Das war vor den Update alles kein Problem.
Eventuell hat sich seit Deinem System welches Du vor 3 Jahren installiert und nie uogedatet hast und dem aktuellen Update von vor ein paar Tagen etwas eingeschlichen.
Wie kann ich denn das Problem herausfinden?
Das letzte Update ist auch keine 3 Jahre her. Ich habe immer mal (unregelmäßig) Updates durchgeführt.
Zitat von: stobor am 05 Mai 2019, 09:53:23
Wie kann ich denn das Problem herausfinden?
Das letzte Update ist auch keine 3 Jahre her. Ich habe immer mal (unregelmäßig) Updates durchgeführt.
Mit den Angaben nicht. Ich wollte Dich zum nachdenken anregen. Es fehlen einfach genaue Daten.
Was war das letzte Update wo Du das Problem noch nicht hattest. Welche Version von FHEM hast Du jetzt genau? Hast Du heute schon ein Update gemacht und mal geschaut ob es wieder ok ist?
Interessant ist von welchen Update zu welchen das Problem aufgetaucht sein könnte.
Was sagt das Logfile.
Ich habe gerade noch mal ein Update durchgeführt:
2019.05.05 09:25:12 1: fhem
2019.05.05 09:25:12 1: RMDIR: ./restoreDir/update/2018-12-30
2019.05.05 09:25:12 1: UPD ./CHANGED
2019.05.05 09:25:12 1: UPD ./MAINTAINER.txt
2019.05.05 09:25:12 1: UPD ./fhem.cfg.demo
2019.05.05 09:25:12 1: UPD ./fhem.pl
2019.05.05 09:25:12 1: UPD FHEM/00_MYSENSORS.pm
2019.05.05 09:25:12 1: UPD FHEM/10_EnOcean.pm
2019.05.05 09:25:12 1: UPD FHEM/10_MYSENSORS_DEVICE.pm
2019.05.05 09:25:12 1: UPD FHEM/10_RESIDENTS.pm
2019.05.05 09:25:12 1: UPD FHEM/20_GUEST.pm
2019.05.05 09:25:12 1: UPD FHEM/20_PET.pm
2019.05.05 09:25:12 1: UPD FHEM/20_ROOMMATE.pm
2019.05.05 09:25:12 1: UPD FHEM/46_TRX_LIGHT.pm
2019.05.05 09:25:12 1: UPD FHEM/49_SSCam.pm
2019.05.05 09:25:12 1: UPD FHEM/50_MOBILEALERTSGW.pm
2019.05.05 09:25:12 1: UPD FHEM/73_AutoShuttersControl.pm
2019.05.05 09:25:12 1: UPD FHEM/73_GardenaSmartBridge.pm
2019.05.05 09:25:12 1: UPD FHEM/76_SMAInverter.pm
2019.05.05 09:25:12 1: UPD FHEM/93_DbRep.pm
2019.05.05 09:25:12 1: UPD FHEM/98_DOIF.pm
2019.05.05 09:25:13 1: UPD FHEM/98_Installer.pm
2019.05.05 09:25:13 1: UPD FHEM/98_Modbus.pm
2019.05.05 09:25:13 1: UPD FHEM/98_RandomTimer.pm
2019.05.05 09:25:13 1: UPD FHEM/98_Text2Speech.pm
2019.05.05 09:25:13 1: UPD FHEM/98_WeekdayTimer.pm
2019.05.05 09:25:13 1: UPD FHEM/98_autocreate.pm
2019.05.05 09:25:13 1: UPD FHEM/98_vitoconnect.pm
2019.05.05 09:25:13 1: UPD FHEM/98_weekprofile.pm
2019.05.05 09:25:13 1: UPD FHEM/RESIDENTStk.pm
2019.05.05 09:25:13 1: UPD FHEM/holiday/ni.holiday
2019.05.05 09:25:13 1: UPD FHEM/holiday/ns.holiday
2019.05.05 09:25:13 1: UPD FHEM/holiday/th.holiday
2019.05.05 09:25:13 1: UPD FHEM/lib/AttrTemplate/httpmod.template
2019.05.05 09:25:13 1: UPD FHEM/lib/AttrTemplate/mqtt2.template
2019.05.05 09:25:13 1: UPD FHEM/lib/fhem_zwave_deviceconfig.xml.gz
2019.05.05 09:25:13 1: UPD demolog/fhem.save
2019.05.05 09:25:13 1: UPD docs/commandref_frame.html
2019.05.05 09:25:13 1: UPD docs/commandref_frame_DE.html
2019.05.05 09:25:13 1: UPD www/gplot/ElsnerWS.gplot
2019.05.05 09:25:13 1: UPD www/gplot/ElsnerWS_2.gplot
2019.05.05 09:25:13 1: UPD www/gplot/ElsnerWS_3.gplot
2019.05.05 09:25:13 1: UPD www/pgm2/f18.js
2019.05.05 09:25:13 1: UPD www/pgm2/fhemweb.js
2019.05.05 09:25:13 1: saving fhem.cfg
2019.05.05 09:25:13 1: saving ./log/fhem.save
2019.05.05 09:25:13 1:
2019.05.05 09:25:13 1: New entries in the CHANGED file:
2019.05.05 09:25:13 1: - feature: 10_RESIDENTS: add home alone mode
2019.05.05 09:25:13 1: - new: 20_PET: new RESIDENTS module type for pets at home
2019.05.05 09:25:13 1: - bugfix: 73_AutoShuttersControl: fix bugs and logic problems
2019.05.05 09:25:13 1: - feature: 98_weekprofile: HMCCU support
2019.05.05 09:25:13 1: - change: 10_MYSENSORS_DEVICE: enhance support for SetExtensions;
2019.05.05 09:25:13 1: separate readings for heatrbeat, smartSleep & NACK
2019.05.05 09:25:13 1: - bugfix: 73_GardenaSmartBridge: fix undefined_value Error
2019.05.05 09:25:13 1: - feature: 98_Text2Speech: add Amazon Polly as new suggested TTS-Engine
2019.05.05 09:25:13 1: due best quality
2019.05.05 09:25:13 1: - bugfix: 73_AutoShuttersControl: fix shading absent and coming home, fix
2019.05.05 09:25:13 1: Reading ASC_Time_PrivacyDriveDown, fix blocking shutter then
2019.05.05 09:25:13 1: shading drive and terrace door open
2019.05.05 09:25:13 1: - change: Newly introduced bank holiday for Thuringia: Weltkindertag (20.09.)
2019.05.05 09:25:13 1: - bugfix: 74_AutoShuttersControl: fix window closed after sunset and ModeUp
2019.05.05 09:25:13 1: absent, fix other bugs
2019.05.05 09:25:13 1: - bugfix: 76_SMAInverter: perl warnings,Forum:#56080.msg933276.html#msg933276
2019.05.05 09:25:13 1: - feature: 73_AutoShuttersControl: add attribut ASC_RainProtection, bugfix
2019.05.05 09:25:13 1: - feature: 73_AutoShuttersControl: add attribut ASC_WindProtection
2019.05.05 09:25:13 1: - bugfix: 73_AutoShuttersControl: fix shutters drive after partyMode off and
2019.05.05 09:25:13 1: shutter have partyMode off attribut
2019.05.05 09:25:13 1: - feature: 93_DbRep: FHEM command "dbReadingsVal" implemented
2019.05.05 09:25:13 1: - change: 49_SSCam: Meta.json and minor code change
2019.05.05 09:25:13 1: - change: 50_MOBILEALERTSGW: Checksum check added
2019.05.05 09:25:13 1: - change: 93_DbRep: check index "Report_Idx" during first DB connect
2019.05.05 09:25:13 1: - change: 98_RandomTimer: remove 59_Twilight dependency
2019.05.05 09:25:13 1: - feature: 93_DbRep: new set "index" command to manage needed indexe for
2019.05.05 09:25:13 1: ... rest of lines skipped.
2019.05.05 09:25:13 1:
2019.05.05 09:25:13 1:
2019.05.05 09:25:13 1: fhemtabletui
2019.05.05 09:25:14 1: nothing to do...
2019.05.05 09:25:14 1: Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2019.05.05 09:25:55 1:
2019.05.05 09:25:55 1: update finished, "shutdown restart" is needed to activate the changes.
Wie kann ich denn herausfinden, wann das letzte Update war?
Im Log war nichts Auffälliges. Ich habe gerade noch einmal das Loglevel erhöht (von 2):
attr global verbose 4
Gib mal
version
in der FHEM Kommandozeile ein.
Zitat von: stobor am 05 Mai 2019, 10:14:29
Wie kann ich denn herausfinden, wann das letzte Update war?
Moin,
restore list updateGruß Otto
restore list update:
Available for restore in update:
2019-01-07
2019-04-26
2019-05-05
Nach dem 7. Januar 2019 war noch alles super.
version liefert:
Latest Revision: 19330
File Rev Last Change
fhem.pl 19328 2019-05-04 19:13:22Z rudolfkoenig
90_at.pm 17561 2018-10-18 14:45:30Z rudolfkoenig
00_CUL.pm 17559 2018-10-18 07:45:07Z rudolfkoenig
10_CUL_HM.pm 19225 2019-04-20 06:53:45Z martinp876
98_dummy.pm 19197 2019-04-16 05:38:59Z rudolfkoenig
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm 19148 2019-04-08 12:24:10Z rudolfkoenig
92_FileLog.pm 19102 2019-04-02 19:48:57Z rudolfkoenig
95_FLOORPLAN.pm 13735 2017-03-19 12:43:53Z UliM
10_FRM.pm 15941 2018-01-20 21:20:20Z jensb
20_FRM_IN.pm 18939 2019-03-17 10:22:23Z jensb
20_FRM_OUT.pm 15928 2018-01-19 21:07:42Z jensb
10_FS20.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
12_HMS.pm 16797 2018-05-29 19:35:43Z rudolfkoenig
02_HTTPSRV.pm 16874 2018-06-15 17:18:55Z neubert
No Id found for 99_myUtils.pm
91_notify.pm 17225 2018-08-29 12:34:29Z rudolfkoenig
98_RandomTimer.pm 19279 2019-04-28 17:10:32Z Beta-User
98_restore.pm 16426 2018-03-17 16:23:45Z rudolfkoenig
49_SSCam.pm 19280 2019-04-28 17:20:21Z DS_Starter
99_SUNRISE_EL.pm 18732 2019-02-25 13:15:34Z rudolfkoenig
98_SVG.pm 18777 2019-03-03 13:16:05Z rudolfkoenig
99_Utils.pm 18920 2019-03-16 09:58:52Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
AttrTemplate.pm 19085 2019-04-01 17:00:24Z rudolfkoenig
No Id found for Base.pm
Blocking.pm 17553 2018-10-17 15:56:35Z rudolfkoenig
Was ist Base.pm
Kannst Du uns den Inhalt einmal geben.
Nur zur Erklärung. Wir sammeln immer noch Infos zu Deinem System.
Dann könntest Du mit einem der beiden Befehle auf den Stand vor dem (Update) Datum gehen:
restore update/2019-01-07
restore update/2019-04-26
Falls Cooltux nichts findet und Du die Geduld verlierst. ;)
Ich suche gerade nach der Base.pm, aber im Verzeichnis fhem/FHEM finde ich die nicht.
Sie liegt hier: FHEM\lib\Device\Firmata
Ist schwierig was zu finden. Wie schaut es denn mit der Prozessauslastung aus wenn die Verzögerungen auf treten. Ich hatte das auch mal und dann war mein Perlprozess meist bei 90 oder gar 100 Prozent.
Also wenn das verzögert wieder an fängt schau mal mit top nach wie die Auslastung ist.
Wo/ wie soll ich denn top eingeben?
In Deiner Linux Shell
Aktuell läuft noch alles, aber ich habe top mal eingegeben:
top - 19:48:26 up 10:40, 1 user, load average: 0,02, 0,03, 0,05
Tasks: 87 gesamt, 1 laufend, 86 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 1,3 be, 3,8 sy, 0,0 ni, 94,8 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3934368 total, 763788 used, 3170580 free, 53116 buffers
KiB Swap: 4079612 total, 0 used, 4079612 free. 488140 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
515 syslog 20 0 255840 1272 808 S 1,0 0,0 1:02.46 rsyslogd
985 mail 20 0 12688 1236 1028 S 0,7 0,0 0:51.07 nullmailer-send
8365 jay 20 0 26544 1608 1188 R 0,7 0,0 0:00.81 top
7 root 20 0 0 0 0 S 0,3 0,0 0:14.06 rcu_sched
28 root 20 0 0 0 0 S 0,3 0,0 0:10.32 kworker/0:1
8389 mail 20 0 39364 1800 1436 S 0,3 0,0 0:00.01 smtp
1 root 20 0 33488 2752 1448 S 0,0 0,1 0:01.90 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:00.52 ksoftirqd/0
4 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/u4:0
8 root 20 0 0 0 0 S 0,0 0,0 0:08.87 rcuos/0
9 root 20 0 0 0 0 S 0,0 0,0 0:07.11 rcuos/1
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/0
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/1
13 root rt 0 0 0 0 S 0,0 0,0 0:01.03 migration/0
14 root rt 0 0 0 0 S 0,0 0,0 0:00.29 watchdog/0
15 root rt 0 0 0 0 S 0,0 0,0 0:00.28 watchdog/1
16 root rt 0 0 0 0 S 0,0 0,0 0:00.94 migration/1
17 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ksoftirqd/1
19 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
20 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
21 root 20 0 0 0 0 S 0,0 0,0 0:00.01 kdevtmpfs
22 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
23 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 writeback
24 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd
25 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 bioset
27 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd
29 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ata_sff
30 root 20 0 0 0 0 S 0,0 0,0 0:00.14 khubd
31 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 md
32 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 devfreq_wq
33 root 20 0 0 0 0 S 0,0 0,0 0:08.06 kworker/1:1
35 root 20 0 0 0 0 S 0,0 0,0 0:00.01 khungtaskd
36 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0
37 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 vmstat
38 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd
39 root 39 19 0 0 0 S 0,0 0,0 0:00.27 khugepaged
40 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark
41 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ecryptfs-kthrea
42 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto
54 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kthrotld
74 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 deferwq
75 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 charger_manager
126 root 20 0 0 0 0 S 0,0 0,0 0:00.01 scsi_eh_0
So gibt's etwas zum vergleichen. Sagt euch das schon etwas?
Das Loglevel reduziere ich mal wieder auf 3, oder ist 4 dauerhaft sinnvoll?
Sagt mir das er sich langweilt ;D
Zitat von: CoolTux am 05 Mai 2019, 20:02:57
Sagt mir das er sich langweilt ;D
So ziemlich :D
load average: 0,02, 0,03, 0,05
Zitatoder ist 4 dauerhaft sinnvoll?
Nein.
Soweit ich das sehe, läuft zum Zeitpunkt der top-Ausgabe kein Fhem.
Zitat von: frober am 06 Mai 2019, 08:12:36
Soweit ich das sehe, läuft zum Zeitpunkt der top-Ausgabe kein Fhem.
Das kann man so pauschal nicht sagen. FHEM taucht nur in der Momentaufnahme nicht in der Top Liste auf. Heißt aber nicht das FHEM nicht läuft.
Ich hatte damals auf der Suche nach delays (1) 99_perfmon.pm aktiviert und mit (2) apptime eingegrenzt.
1. Modul 99_perfmon.pm in den Unterordner FHEM kopieren und fhem restarten => Logeinträge, wenn Verzögerungen > 1 Sek. auftreten
2. In Fhem-Befehlszeile apptime eingeben => Damit wird es aktiv. Nochmaliger Aufruf zeigt die Module und deren Zeitverhalten.
Jetzt habe ich gerade wieder das Phänomen, dass FHEM langsamer zu werden scheint.
fhem "set Arduino_Pin6_Summer on-for-timer 0.25";;\
lässt den Summer deutlich länger summen.
TOP liefert:
top - 10:03:52 up 9 days, 11:46, 1 user, load average: 1,00, 1,02, 1,05
Tasks: 85 gesamt, 2 laufend, 83 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 50,1 be, 0,0 sy, 0,0 ni, 49,9 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3934368 total, 2041920 used, 1892448 free, 175248 buffers
KiB Swap: 4079612 total, 0 used, 4079612 free. 1582076 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
1056 fhem 20 0 212492 134732 3548 R 99,8 3,4 697:13.50 perl
1 root 20 0 33480 2760 1448 S 0,0 0,1 0:01.91 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.04 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:13.04 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0,0 0,0 5:13.87 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 3:14.69 rcuos/0
9 root 20 0 0 0 0 S 0,0 0,0 2:40.53 rcuos/1
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/0
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/1
13 root rt 0 0 0 0 S 0,0 0,0 0:25.92 migration/0
14 root rt 0 0 0 0 S 0,0 0,0 0:06.22 watchdog/0
15 root rt 0 0 0 0 S 0,0 0,0 0:06.12 watchdog/1
16 root rt 0 0 0 0 S 0,0 0,0 0:19.16 migration/1
17 root 20 0 0 0 0 S 0,0 0,0 0:00.18 ksoftirqd/1
19 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
20 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
21 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs
22 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
23 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 writeback
24 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd
25 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 bioset
27 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd
28 root 20 0 0 0 0 S 0,0 0,0 3:58.99 kworker/0:1
29 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ata_sff
30 root 20 0 0 0 0 S 0,0 0,0 0:00.14 khubd
31 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 md
32 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 devfreq_wq
33 root 20 0 0 0 0 S 0,0 0,0 3:32.13 kworker/1:1
35 root 20 0 0 0 0 S 0,0 0,0 0:00.31 khungtaskd
36 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0
37 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 vmstat
38 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd
39 root 39 19 0 0 0 S 0,0 0,0 0:03.64 khugepaged
40 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark
41 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ecryptfs-kthrea
42 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto
54 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kthrotld
74 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 deferwq
75 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 charger_manager
76 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/0:2
nachdem ich in FHEM
shutdown restart gesendet habe, reagirt der Befehl (on-for-timer) wieder normal, und TOP liefert:
top - 10:17:24 up 9 days, 11:59, 1 user, load average: 0,07, 0,14, 0,54
Tasks: 85 gesamt, 1 laufend, 84 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 0,2 be, 0,2 sy, 0,0 ni, 99,7 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3934368 total, 1974348 used, 1960020 free, 175264 buffers
KiB Swap: 4079612 total, 0 used, 4079612 free. 1583972 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
30375 jay 20 0 26532 1676 1188 R 0,3 0,0 0:02.90 top
1 root 20 0 33480 2760 1448 S 0,0 0,1 0:01.93 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.04 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:13.05 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0,0 0,0 5:14.23 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 3:14.91 rcuos/0
9 root 20 0 0 0 0 S 0,0 0,0 2:40.71 rcuos/1
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/0
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/1
13 root rt 0 0 0 0 S 0,0 0,0 0:25.94 migration/0
14 root rt 0 0 0 0 S 0,0 0,0 0:06.23 watchdog/0
15 root rt 0 0 0 0 S 0,0 0,0 0:06.13 watchdog/1
16 root rt 0 0 0 0 S 0,0 0,0 0:19.17 migration/1
17 root 20 0 0 0 0 S 0,0 0,0 0:00.18 ksoftirqd/1
19 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
20 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
21 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs
22 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
23 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 writeback
24 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd
25 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 bioset
27 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd
28 root 20 0 0 0 0 S 0,0 0,0 3:59.31 kworker/0:1
29 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ata_sff
30 root 20 0 0 0 0 S 0,0 0,0 0:00.14 khubd
31 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 md
32 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 devfreq_wq
33 root 20 0 0 0 0 S 0,0 0,0 3:32.56 kworker/1:1
35 root 20 0 0 0 0 S 0,0 0,0 0:00.31 khungtaskd
36 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0
37 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 vmstat
38 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd
39 root 39 19 0 0 0 S 0,0 0,0 0:03.71 khugepaged
40 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark
41 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ecryptfs-kthrea
42 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto
54 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kthrotld
74 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 deferwq
75 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 charger_manager
76 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/0:2
fhem bewegt sich auch immer mal aus der ersten Zeile weg. Das war vor dem restart nicht so.
Idee?
Vor dem restart hat er sich also nicht mehr gelangweilt. ;) :'(
FHEM zickt da eindeutig. Ich habe zur Analyse freezemon und nicht perfmon laufen.
Du könntest auch einfach nur den event monitor nutzen. Dort siehst Du vielleicht, ob ein device FHEM mit events überflutet. Passend zu meiner Ausdrucksweise: bei mir habe ich meinen Überflutungssensor so als Übeltäter identifizieren können, der bei hoher Luftfeuchtigkeit permanent "meldet" und FHEM deutlich spürbar bremst.
Grüße Markus
Ok, heißt dass, beim nächsten Auftreten einfach in der Web-Maske "Event monitor" anklciken, und schauen, was da einläuft?
1056 fhem 20 0 212492 134732 3548 R 99,8 3,4 697:13.50 perl
fhem versetzt die CPU da ziemlich an den Anschlag
ZitatOk, heißt dass, beim nächsten Auftreten einfach in der Web-Maske "Event monitor" anklciken, und schauen, was da einläuft?
Kannst Du so probieren. Aber kann natürlich auch eine ganz andere Ursache sein, z.B. ein blockierendes device(wobei ich dann eine geringe CPU-Auslastung erwarten würde).
Mein System hat eine ähnliche Macke. Irgendwann nach 3-4 Tagen steigt plötzlich der Raumverbrauch bis dann der ganze Pi nach 30min nicht mehr reagiert. Das sehe ich auch nur im Plot das der RAM Verbrauch ansteigt. Nach einem Power Off läuft das System dann wieder 4 Tage stabil bis das gleiche passiert.
Es ist mal wieder soweit. FHEM ist wieder extrem langsam. Alle Vorgänge dauern extrem lange oder werden sehr verzögert ausgeführt (Lampe für 3sec einschalten startet zunächst verzögert un dann bleibt die Lampe auch länger an).:
top - 13:59:52 up 12 days, 4:04, 1 user, load average: 1,00, 1,01, 1,05
Tasks: 85 gesamt, 2 laufend, 83 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 50,2 be, 0,0 sy, 0,0 ni, 49,8 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3934368 total, 2069576 used, 1864792 free, 178220 buffers
KiB Swap: 4079612 total, 0 used, 4079612 free. 1587836 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
1050 fhem 20 0 211080 133476 3604 R 100,0 3,4 1235:08 perl
1 root 20 0 33484 2772 1448 S 0,0 0,1 0:01.93 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.05 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:23.22 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:+
7 root 20 0 0 0 0 S 0,0 0,0 9:25.22 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 5:48.76 rcuos/0
9 root 20 0 0 0 0 S 0,0 0,0 4:52.87 rcuos/1
Der Aufruf der FHEM WebGUI dauert ebenfalls ewig.
Der Event-Monitor ist entsprechend langsam, liefert aber nur die üblichen Ereignisse/Meldungen.
Ein shutdown restart in der FHEM WebGUI entspannt die Situation und ales läuft wieder normal:
top - 14:11:45 up 12 days, 4:16, 1 user, load average: 0,07, 0,59, 0,87
Tasks: 84 gesamt, 1 laufend, 83 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 0,7 be, 0,2 sy, 0,0 ni, 99,2 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3934368 total, 2003916 used, 1930452 free, 178220 buffers
KiB Swap: 4079612 total, 0 used, 4079612 free. 1589988 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
5169 fhem 20 0 126536 63948 2456 S 1,0 1,6 0:08.46 perl
3464 jay 20 0 26560 1624 1188 R 0,3 0,0 0:01.70 top
1 root 20 0 33484 2772 1448 S 0,0 0,1 0:01.94 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.05 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:23.24 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:+
7 root 20 0 0 0 0 S 0,0 0,0 9:25.51 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 5:48.87 rcuos/0
Hat jemand eine Idee?
fheminfo liefert:
System Info
ConfigType: configFile
SVN rev: 19330
OS: linux
Perl: 5.18.2
uniqueId: de3...
Ob ein update stable hilft?
Zitat von: stobor am 28 Juli 2019, 14:18:57
Ob ein update stable hilft?
Hi,
was genau meinst Du damit? Mir ist ein solcher Befehl nicht bekannt.
Du musst versuchen herauszubekommen was FHEM offenbar in die hohe Last bringt.
Mit Apptime z.B. https://wiki.fhem.de/wiki/Apptime
Oder freezemon.
Gruß Otto
Wann genau muss ich denn Apptime verwenden? Wenn das System wieder langsam ist? Oder kann ich das jetzt starten und bei denProblemen erneut aufrufen?
Apptime kannst du jederzeit starten, er zeichnet dann alles auf.
Lies Dir am besten mal https://wiki.fhem.de/wiki/Apptime (https://wiki.fhem.de/wiki/Apptime) durch.
Um natürlich an das Ergebnis bei 100% CPU Auslastung zu kommen, müsste FHEM Web erreichbar sein, um sich das Ergebnis anzeigen zu lassen.
(Ob nach einem shutdown restart die Daten noch vorhanden sind, weiß ich nicht)
Ich weiß nicht, ob die Frage schon gestellt wurde, wie loggst du deine Daten? Logfile oder per SQL?
Ich hatte mal das Problem, dass ich meine Daten per SQL (MariaDB) ohne das Attribut "asyncMode" geloggt habe (Stichwort nonBlocking).
Dies führte bei mir damals zu einem ähnlichen Verhalten wie bei Dir.
Gruß
Mathze
Ich werde dann Apptime mal starten. Vielleicht ist beim nächsten Crash etwas zu erkennen. FHEM Web ist noch erreichbar, aber sehr langsam. Das würde zum Analysieren ja reichen.
Ich lasse meine Logs in Files schreiben.
mein Bauch sagt mir, das Du auch das Betriebssystem entsprechend updaten solltest. Bei mir sponnen auch mal ein paar Perl Bibliotheken rum und es war auch sehr zäh geworden.
Hast Du in dem global Device deinen DNS hinterlegt?
Steht "Merkwürdiges" in der Datei /var/log/syslog? more /var/log/syslog
Werden Fehlermeldung bei der Ausgabe vom Befehl "dmesg" angezeigt - (insbesondere Disk und Netz)? dmesg | more
Wie trage ich denn den DNS ein?
Ich nutze untendrunter Ubuntu; ich meine in der Version 14. Kann ich risikolos auf die neuste Version updaten? Ich habe mich bisher nicht getraut, um FHEM nicht zu ,,stören".
Zitat von: stobor am 29 Juli 2019, 16:44:19
Wie trage ich denn den DNS ein?
In fhem:
attr global dnsServer <IP-Adresse deines Routers>ohne die <>
DNS ist eingetragen. Mal abwarten.
Ich kann über dmesg | more nichts Auffälliges finden: s. Anlage
more /var/log/syslog liefert wiederkehrende Einträge:
Jul 29 06:54:54 hausautomation nullmailer[985]: Starting delivery: protocol: smtp host: smtp.ionos.de file: 1563055201.26239
Jul 29 06:54:54 hausautomation nullmailer[985]: Starting delivery, 215 message(s) in queue.
Jul 29 06:54:54 hausautomation nullmailer[20614]: smtp: Failed: 530 Authentication required
Jul 29 06:54:54 hausautomation nullmailer[985]: Sending failed: Permanent error in sending the message
Kann ich irgendwie herausfinden, welcher Email-Auftrag Probleme macht. Ich habe bisher keine Emails vermisst.
Beim Systemneustart bekomme ich angezeigt:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-164-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Mon Jul 29 22:51:04 CEST 2019
System load: 0.07 Processes: 86
Usage of /: 3.3% of 105.59GB Users logged in: 0
Memory usage: 8% IP address for p2p1: 192.168.178.20
Swap usage: 0%
Graph this data and manage this system at:
https://landscape.canonical.com/
69 packages can be updated.
55 updates are security updates.
New release '16.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Ist es sinnvoll bzw. möglich, do-release-upgrade auszuführen? Oder kann das FHEM stören - sprich: läuft FHEM unter der Version nicht? Ich habe mich das Upgrade bisher nie getraut, da FHEM immer fehlerfrei lief.
FHEM selbst würde ich dann vermutlich auch aktualisieren (müssen).
du solltest einfach nur ein update machen ...
unter Debian (klappt aber auch unter Ubuntu): sudo apt-get update && sudo apt-get upgrade
Zitat von: Wuppi68 am 30 Juli 2019, 11:03:45
du solltest einfach nur ein update machen ...
unter Debian (klappt aber auch unter Ubuntu): sudo apt-get update && sudo apt-get upgrade
Was meinst Du mit "einfach nur"?
Entspricht Dein
sudo apt-get update && sudo apt-get upgrade dem
do-release-upgrade, oder würde ich bei Deinem Vorschlag bei Version 14 bleiben, oder ...?
update und upgrade ändert nichts an der Haupt Version. Es bringt einfach alles auf den aktuellen Stand innerhalb von diesem Release. Es ist aus Sicherheitsgründen angeraten dies zu tun und stört die anderen Systeme normalerweise nicht.
Gruß Otto
Zitat von: stobor am 29 Juli 2019, 23:11:52
DNS ist eingetragen. Mal abwarten.
Ich kann über dmesg | more nichts Auffälliges finden: s. Anlage
more /var/log/syslog liefert wiederkehrende Einträge:
Jul 29 06:54:54 hausautomation nullmailer[985]: Starting delivery: protocol: smtp host: smtp.ionos.de file: 1563055201.26239
Jul 29 06:54:54 hausautomation nullmailer[985]: Starting delivery, 215 message(s) in queue.
Jul 29 06:54:54 hausautomation nullmailer[20614]: smtp: Failed: 530 Authentication required
Jul 29 06:54:54 hausautomation nullmailer[985]: Sending failed: Permanent error in sending the message
Kann ich irgendwie herausfinden, welcher Email-Auftrag Probleme macht. Ich habe bisher keine Emails vermisst.
Beim Systemneustart bekomme ich angezeigt:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-164-generic x86_64)
* Documentation: https://help.ubuntu.com/
System information as of Mon Jul 29 22:51:04 CEST 2019
System load: 0.07 Processes: 86
Usage of /: 3.3% of 105.59GB Users logged in: 0
Memory usage: 8% IP address for p2p1: 192.168.178.20
Swap usage: 0%
Graph this data and manage this system at:
https://landscape.canonical.com/
69 packages can be updated.
55 updates are security updates.
New release '16.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Ist es sinnvoll bzw. möglich, do-release-upgrade auszuführen? Oder kann das FHEM stören - sprich: läuft FHEM unter der Version nicht? Ich habe mich das Upgrade bisher nie getraut, da FHEM immer fehlerfrei lief.
FHEM selbst würde ich dann vermutlich auch aktualisieren (müssen).
Das ist aber schon ein sehr altes System. Je länger Du wartest um so aufwändiger KANN es werden auf die aktuellste Version zu kommen.
Meint ihr also, dass ich ein sudo apt-get update && sudo apt-get upgrade gefolgt von einem do-release-upgrade problemlos durchführen kann, und FHEM davon unbeeindruckt sein müsste?
Zitat von: stobor am 30 Juli 2019, 11:46:38
Meint ihr also, dass ich ein sudo apt-get update && sudo apt-get upgrade gefolgt von einem do-release-upgrade problemlos durchführen kann, und FHEM davon unbeeindruckt sein müsste?
Nein, meine ich nicht.
Ich mache System Releasewechsel generell durch Neuinstallation des Systems und Backup und Restore von FHEM.
Aber das ist nur meinen Meinung.
Zitat von: stobor am 30 Juli 2019, 11:46:38
Meint ihr also, dass ich ein sudo apt-get update && sudo apt-get upgrade gefolgt von einem do-release-upgrade problemlos durchführen kann, und FHEM davon unbeeindruckt sein müsste?
Sowas kann man beim besten Willen nicht meinen oder behaupten. Du musst selber wissen was Du tust. Du bist der Herr über Dein System. Das ist ja das schöne an Linux.
Aber die Reihenfolge war zu mindest schon mal richtig. Alles andere ergibt sich dann. Ein Backup ist im übrigen immer ein sehr schöner Anker für zu schwache Update Herzen.
Mal meine Erfahrung dazu. Ich habe in den letzten Jahren diverse Debian Systeme und vor 2015 auch diverse Ubuntu Systeme durch updates auf den neusten Stand gebracht. Über Distributions Releases hinaus.
Dann werde ich mich da einmal heranwagen.
Ich bin jetzt nicht der Linux-Experte. Habt ihr einen Tipp, wie ich das gesamt-System sichern kann? Derzeit nutze Ich Ubuntu auf einem Intel NUC und verbinde mich von meinem Windows-PC per Putty. Der NUC hat keinen Monitor und Tastatur angeschlossen. Mir kommt spontan sonst nur der Festplattenausbau in den Kopf, um danach dann die Platte zu clonen.
Zitat von: stobor am 30 Juli 2019, 13:12:49
Dann werde ich mich da einmal heranwagen.
Ich bin jetzt nicht der Linux-Experte. Habt ihr einen Tipp, wie ich das gesamt-System sichern kann? Derzeit nutze Ich Ubuntu auf einem Intel NUC und verbinde mich von meinem Windows-PC per Putty. Der NUC hat keinen Monitor und Tastatur angeschlossen. Mir kommt spontan sonst nur der Festplattenausbau in den Kopf, um danach dann die Platte zu clonen.
mache den 1. Teil mit update und upgrade, da geht die Fehlerquote gegen 0
für ein generelles release upgrade würde ich auch Ottos weg wählen ...
FHEM sichern [inclusive System Startup Dateien (/etc/init.d/... und /etc/systemd/system/...)]
Platte ausbauen
neue Platte einbauen
System installieren
FHEM zurück sichern
Zitat von: stobor am 30 Juli 2019, 13:12:49
Dann werde ich mich da einmal heranwagen.
Ich bin jetzt nicht der Linux-Experte. Habt ihr einen Tipp, wie ich das gesamt-System sichern kann? Derzeit nutze Ich Ubuntu auf einem Intel NUC und verbinde mich von meinem Windows-PC per Putty. Der NUC hat keinen Monitor und Tastatur angeschlossen. Mir kommt spontan sonst nur der Festplattenausbau in den Kopf, um danach dann die Platte zu clonen.
Wenn Du eher weniger Erfahrung hast würde ich die HDD clonen.
Dazu noch ein paar meiner Notizen
https://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html
https://heinz-otto.blogspot.com/2019/07/neues-linux-system-nacharbeit.html
https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
Und putty nehme ich schon lange nicht mehr. Windows kann das ohne (https://heinz-otto.blogspot.com/2018/06/windows-hat-jetzt-ssh.htmlU). Gefällt mir persönlich besser. :D
Und andersherum geht auch, von linux per ssh auf Windows (https://heinz-otto.blogspot.com/2019/05/windows-von-fhem-aus-steuern.html)
Ich würde es machen wie Wuppi68 sagt, leg die Original Platte vorsichtig beiseite und nimm eine neue, vielleicht auch erstmal ein temporäre zum probieren. Oder probiere in einer VM auf einer ganz anderen Maschine, wenn Du ein sicheres Gefühl hast dann mach es richtig.
So, ich hatte zunächst nur die alte Ubuntu-Version auf Vordermann gebracht. Danach lief noch alles.
Jetzt habe ich noch Ubuntu per do-release-upgrade auf einen neueren Stand aktualisiert (Version 16.04).
Jetzt startet FHEM nicht mehr automatisch. Ich muss es mit sudo perl fhem.pl fhem.cfg immer manuell starten.
Was kann ich tun, damit es wieder automatisch klappt?
Ich würde da jetzt an /etc/rc.local denken wollen.
Ich müsste mich einlesen, also aus dem Gedächtnis:
Da trägst Du Deine Befehlszeile ein. Allerdings muss da nach meiner Erinnerung wirklich alles absolute Pfadangaben haben, auch perl selbst.
Wo bei Dir perl rumliegt, findest Du über den Konsolenbefehl "which perl" heraus.
SystemV und systemd sind unterschiedliche Init Prozesse. Eigentlich hätte eine Anpassung statt finden sollen. Nun musst Du von Hand an passen. Du brauchst also für systemd eine service Datei.
Komme aktuell an keine ran, eventuell kann ein anderer User Dir den Inhalt seiner geben.
Im contrib-Verzeichnis sollten .service Dateien liegen. (contrib/init-scripts/fhem.service)
Das contrib wird doch aber nicht aktualisiert? Also bei alten Installationen ist dort eventuell nichts aktuelles.
Besser von hier holen: https://svn.fhem.de/trac/browser/trunk/fhem
Gruß Otto
Danke für eure Hilfe.
Jetzt bin ich doch den Weg gegangen, das System omplett neu aufzusetzen. Nach ein paar Schwierigkeiten läuft es jetzt aber. Mal sehen, ob sich das Performance-Problem in den nächsten Tagen wieder einschleicht.