[Gelöst] Ungeplante Fhem-Neustarts

Begonnen von Gisbert, 10 September 2022, 15:07:46

Vorheriges Thema - Nächstes Thema

Gisbert

Hallo Jörg,

wie berichtet hab ich mit regelmäßigen FHEM-Neustarts meiner Installation zu tun, ohne dass ich über negative Auswirkungen berichten könnte.

Auf meinem HP T610 mit einer 250 GB großen SSD und 4 GB (?, bin mir nicht sicher) Hauptspeicher läuft ein Debian 11, und auf dem alles mögliche:
Fhem, Unifi-Controller, Pi-Hole, MQTT, Rhasspy, Signal ...

Ich hab oft ca. 20 Freezers der milderen Sorte pro Tag, keine langen Hänger, häufig sind dann Internetabfragen involviert, von denen ich sehr viele hab.

Beim letzten, ungeplantem Fhem-Neustart hab ich keine Einträge im freezmonhlog gefunden.

Könnte mehr Hauptspeicher (8GB statt 4) helfen?

Ich hab auch ein Fhem-Device zum Überwachen des HP T610, hier ein list:

Internals:
   CFGFN      ./FHEM/NetzwerkServerTV.cfg
   DEF        2 5 10 10
   FUUID      5c99fcdc-f33f-e986-bd6a-d3c2edce4e82d091
   INTERVAL_BASE 60
   INTERVAL_MULTIPLIERS 2 5 10 10
   MODE       local
   NAME       T610.Sysmon
   NOTIFYDEV  global,TYPE=SYSMON
   NR         1111
   NTFY_ORDER 50-T610.Sysmon
   STATE      Temp: 56.9°C

last Fhem start: 10.09.2022 10:50

last server start: 16.08.2022 13:04
   TYPE       SYSMON
   eventCount 502
   READINGS:
     2022-09-10 15:00:57   cpu0_freq       825
     2022-09-10 15:00:57   cpu0_freq_stat  748.00 1798.00 894.21
     2022-09-10 15:00:58   cpu0_idle_stat  0.00 98.14 89.92
     2022-09-10 15:00:58   cpu0_temp       56.75
     2022-09-10 15:00:58   cpu0_temp_avg   56.9
     2022-09-10 15:00:58   cpu0_temp_stat  42.38 73.00 56.95
     2022-09-10 15:00:57   cpu1_freq       826
     2022-09-10 15:00:57   cpu1_freq_stat  695.00 1663.00 843.48
     2022-09-10 15:00:58   cpu1_idle_stat  0.00 97.83 88.71
     2022-09-10 15:00:58   cpu_core_count  8192
     2022-09-10 15:00:57   cpu_freq        825
     2022-09-10 15:00:57   cpu_freq_stat   748.00 1798.00 894.21
     2022-09-10 15:00:58   cpu_idle_stat   1.49 97.62 89.32
     2022-09-10 10:51:35   cpu_model_name  AMD G-T56N Processor
     2022-09-10 15:00:58   eth0            not available
     2022-09-10 15:00:58   eth0_diff       not available
     2022-09-10 15:00:58   fhemstarttime   1662799821
     2022-09-10 15:00:58   fhemstarttime_text 10.09.2022 10:50:21
     2022-09-10 15:00:58   fhemstarttime_text2 10.09.2022 10:50
     2022-09-10 15:00:58   fhemuptime      15036
     2022-09-10 15:00:58   fhemuptime_text 0 days, 04 hours, 10 minutes
     2022-09-10 15:00:58   idletime        471 0.02 %
     2022-09-10 15:00:58   idletime_text   0 days, 00 hours, 07 minutes (0.02 %)
     2022-09-10 15:00:58   loadavg         0.25 0.21 0.21
     2022-09-10 10:51:35   perl_version    v5.32.1
     2022-09-10 15:00:58   ram             Total: 3398.25 MB, Used: 2293.02 MB, 67.48 %, Free: 486.15 MB
     2022-09-10 15:00:58   ram_used        2293.02 MB
     2022-09-10 15:00:58   ram_used_stat   522.54 3255.02 2339.23
     2022-09-10 15:00:58   root            Total: 15059 MB, Used: 11979 MB, 85 %, Available: 2246 MB at /
     2022-09-10 15:00:58   starttime       1660647892
     2022-09-10 15:00:58   starttime_text  16.08.2022 13:04:52
     2022-09-10 15:00:58   starttime_text2 16.08.2022 13:04
     2022-09-10 15:00:58   stat_cpu        35376679 185230 7103813 386104066 148858 0 570243
     2022-09-10 15:00:58   stat_cpu0       18260362 95162 3516486 192725233 56640 0 228798
     2022-09-10 15:00:58   stat_cpu0_diff  1020 0 232 10621 1 0 11
     2022-09-10 15:00:58   stat_cpu0_percent 8.58 0.00 1.95 89.36 0.01 0.00 0.09
     2022-09-10 15:00:58   stat_cpu0_text  user: 8.58 %, nice: 0.00 %, sys: 1.95 %, idle: 89.36 %, io: 0.01 %, irq: 0.00 %, sirq: 0.09 %
     2022-09-10 15:00:58   stat_cpu1       17116316 90067 3587327 193378832 92218 0 341444
     2022-09-10 15:00:58   stat_cpu1_diff  1346 0 242 10273 1 0 14
     2022-09-10 15:00:58   stat_cpu1_percent 11.33 0.00 2.04 86.50 0.01 0.00 0.12
     2022-09-10 15:00:58   stat_cpu1_text  user: 11.33 %, nice: 0.00 %, sys: 2.04 %, idle: 86.50 %, io: 0.01 %, irq: 0.00 %, sirq: 0.12 %
     2022-09-10 15:00:58   stat_cpu_diff   2366 0 473 20894 2 0 25
     2022-09-10 15:00:58   stat_cpu_percent 9.96 0.00 1.99 87.94 0.01 0.00 0.11
     2022-09-10 15:00:58   stat_cpu_text   user: 9.96 %, nice: 0.00 %, sys: 1.99 %, idle: 87.94 %, io: 0.01 %, irq: 0.00 %, sirq: 0.11 %
     2022-09-10 15:00:58   swap            Total: 3556.00 MB, Used: 806.00 MB,  22.67 %, Free: 2750.00 MB
     2022-09-10 15:00:58   swap_used_stat  0.00 2697.23 801.29
     2022-09-10 15:00:58   uptime          2166965
     2022-09-10 15:00:58   uptime_text     25 days, 01 hours, 56 minutes
     2022-09-10 15:00:58   wlan0           not available
     2022-09-10 15:00:58   wlan0_diff      not available
   helper:
     sys_cpu0_freq 1
     sys_cpu0_temp 1
     sys_cpu1_freq 1
     sys_cpu1_temp 0
     sys_cpu2_freq 0
     sys_cpu2_temp 0
     sys_cpu3_freq 0
     sys_cpu3_temp 0
     sys_cpu4_freq 0
     sys_cpu4_temp 0
     sys_cpu5_freq 0
     sys_cpu5_temp 0
     sys_cpu6_freq 0
     sys_cpu6_temp 0
     sys_cpu7_freq 0
     sys_cpu7_temp 0
     sys_cpu_freq_rpi_bbb 1
     sys_cpu_temp_bbb 0
     sys_cpu_temp_rpi 0
     sys_fb     0
     sys_power_ac 0
     sys_power_bat 0
     sys_power_usb 0
     u_first_mark 1
     bm:
       SYSMON_Get:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        10.09. 14:25:56
         max        0.0786612033843994
         tot        0.0787832736968994
         mAr:
           HASH(0x5601e47ee568)
           T610.Sysmon
           update
       SYSMON_Notify:
         cnt        505
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        10.09. 14:44:56
         max        7.39097595214844e-05
         tot        0.0105834007263184
         mAr:
           HASH(0x5601e47ee568)
           HASH(0x5601e47ee568)
       SYSMON_Set:
         cnt        155
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        10.09. 11:25:35
         max        0.000427961349487305
         tot        0.0256001949310303
         mAr:
           HASH(0x5601e47ee568)
           T610.Sysmon
           ?
     cur_readings_map:
       cpu0_freq  CPU frequency (core 0)
       cpu0_freq_stat CPU frequency (core 0) stat
       cpu0_idle_stat CPU0 min/max/avg (idle)
       cpu0_temp  CPU temperature (core 0)
       cpu0_temp_avg Average CPU temperature (core 0)
       cpu0_temp_stat CPU temperature stat (core 0)
       cpu1_freq  CPU frequency (core 1)
       cpu1_freq_stat CPU frequency (core 1) stat
       cpu1_idle_stat CPU1 min/max/avg (idle)
       cpu2_idle_stat CPU2 min/max/avg (idle)
       cpu3_idle_stat CPU3 min/max/avg (idle)
       cpu4_idle_stat CPU4 min/max/avg (idle)
       cpu5_idle_stat CPU5 min/max/avg (idle)
       cpu6_idle_stat CPU6 min/max/avg (idle)
       cpu7_idle_stat CPU7 min/max/avg (idle)
       cpu_bogomips BogoMIPS
       cpu_core_count Number of CPU cores
       cpu_freq   CPU frequency
       cpu_freq_stat CPU frequency stat
       cpu_idle_stat CPU min/max/avg (idle)
       cpu_model_name CPU model name
       date       Date
       eth0       Network adapter eth0
       eth0_diff  Network adapter eth0 (diff)
       eth0_ip    Network adapter eth0 (IP)
       eth0_ip6   Network adapter eth0 (IP6)
       eth0_rx    Network adapter eth0 (RX)
       eth0_speed Network adapter eth0 (speed)
       eth0_tx    Network adapter eth0 (TX)
       fhemstarttime Fhem start time
       fhemstarttime_text Fhem start time
       fhemuptime System up time
       fhemuptime_text FHEM up time
       idletime   Idle time
       idletime_text Idle time
       io_sda     TEST
       io_sda_diff TEST
       io_sda_raw TEST
       loadavg    Load average
       loadavg_1  Load average 1
       loadavg_15 Load average 15
       loadavg_5  Load average 5
       perl_version Perl Version
       ram        RAM
       ram_free   RAM free
       ram_free_percent RAM free %
       ram_total  RAM total
       ram_used   RAM used
       ram_used_stat RAM used stat
       root       Filesystem /
       starttime  System start time
       starttime_text System start time
       stat_cpu   CPU statistics
       stat_cpu0  CPU0 statistics
       stat_cpu0_diff CPU0 statistics (diff)
       stat_cpu0_percent CPU0 statistics (diff, percent)
       stat_cpu0_text CPU0 statistics (text)
       stat_cpu1  CPU1 statistics
       stat_cpu1_diff CPU1 statistics (diff)
       stat_cpu1_percent CPU1 statistics (diff, percent)
       stat_cpu1_text CPU1 statistics (text)
       stat_cpu2  CPU2 statistics
       stat_cpu2_diff CPU2 statistics (diff)
       stat_cpu2_percent CPU2 statistics (diff, percent)
       stat_cpu2_text CPU2 statistics (text)
       stat_cpu3  CPU3 statistics
       stat_cpu3_diff CPU3 statistics (diff)
       stat_cpu3_percent CPU3 statistics (diff, percent)
       stat_cpu3_text CPU3 statistics (text)
       stat_cpu4  CPU4 statistics
       stat_cpu4_diff CPU4 statistics (diff)
       stat_cpu4_percent CPU4 statistics (diff, percent)
       stat_cpu4_text CPU4 statistics (text)
       stat_cpu5  CPU5 statistics
       stat_cpu5_diff CPU5 statistics (diff)
       stat_cpu5_percent CPU5 statistics (diff, percent)
       stat_cpu5_text CPU5 statistics (text)
       stat_cpu6  CPU6 statistics
       stat_cpu6_diff CPU6 statistics (diff)
       stat_cpu6_percent CPU6 statistics (diff, percent)
       stat_cpu6_text CPU6 statistics (text)
       stat_cpu7  CPU7 statistics
       stat_cpu7_diff CPU7 statistics (diff)
       stat_cpu7_percent CPU7 statistics (diff, percent)
       stat_cpu7_text CPU7 statistics (text)
       stat_cpu_diff CPU statistics (diff)
       stat_cpu_idle_percent CPU statistics idle %
       stat_cpu_io_percent CPU statistics io %
       stat_cpu_irq_percent CPU statistics irq %
       stat_cpu_nice_percent CPU statistics nice %
       stat_cpu_percent CPU statistics (diff, percent)
       stat_cpu_sirq_percent CPU statistics sirq %
       stat_cpu_sys_percent CPU statistics sys %
       stat_cpu_text CPU statistics (text)
       stat_cpu_user_percent CPU statistics user %
       swap       swap
       swap_free  swap free
       swap_total swap total
       swap_used  swap used
       swap_used_percent swap used %
       swap_used_stat swap used stat
       uptime     System up time
       uptime_text System up time
       wlan0      Network adapter wlan0
       wlan0_diff Network adapter wlan0 (diff)
       wlan0_ip   Network adapter wlan0 (IP)
       wlan0_ip6  Network adapter wlan0 (IP6)
       wlan0_rx   Network adapter wlan0 (RX)
       wlan0_speed Network adapter wlan0 (speed)
       wlan0_tx   Network adapter wlan0 (TX)
     excludes:
Attributes:
   comment    https://forum.fhem.de/index.php/topic,116301.msg1105767.html#msg1105767
ram_used {ReadingsVal("$name","ram",0) =~ m/Used:.(\d+.\d+.MB)/;; return $1}
Dies wird aber letztlich nicht weiterbenutzt, da die used % in ram steht.
   group      Performance
   icon       hewlettpackard
   room       Network
   stateFormat Temp: cpu0_temp_avg°C

last Fhem start: fhemstarttime_text2

last server start: starttime_text2
   userReadings fhemstarttime_text2 {substr((ReadingsVal($name,'fhemstarttime_text','')),0,16)},
starttime_text2 {substr((ReadingsVal($name,'starttime_text','')),0,16)},
ram_used {ReadingsVal("$name","ram",0) =~ m/Used:.(\d+.\d+.MB)/;; return $1}


Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

KölnSolar

ram sieht doch gut aus. Logge es doch mal, um rauszufinden, ob Du mehr Speicher brauchst.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Na ja, nach 4h uptime kann man wenig sagen.

Zitat aus meinem anderen Beitrag:
ZitatWenn vorher nichts auffälliges im Log steht, würde ich auf systemd als Verursacher tippen, was bedeutet, dass dein System hin und wieder hängt, warum auch immer; es gibt Tools dazu wie Freezemon.  Speicherprobleme halte ich für eher unwahrscheinlich, aber das zu monitoren kann auch nicht schaden.
Würde auf schlecht optimierte Eventverarbeitung iVm. sehr vielen Events tippen.

Zu den freezes: Wenn es "Internet-Devices" sind, die hängen, könnte eine (zum Aufrufe-Zeitpunkt) fehlende Internetleitung das Problem verursachen. Würde man das globale dns-Attribut checken.

RAM: muss man im Lauf der Zeit ansehen. Da bei dir noch ein paar andere Dienste laufen, kannst du z.B. mal eine Weile auf "top" starren, da siehst du ggf. auch, wieviele Perl-Prozesse parallel laufen. An sich sollte es bei deiner x64-Kiste auch egal sein, wenn der anfangen sollte zu swappen, beim Pi wäre das tödlich...
Wie viele FHEM-Prozesse jeweils laufen (forks) kann man mit systemctl ermitteln. Wäre auch interessant.

(OT) "autoremove" iVm. apt ist bekannt?

Zum letzten:
count NTFY_ORDER=.+
count NOTIFYDEV=.+
Um was es sich handelt, zeigt dir dann  jeweils list mit diesen devspec.

Und dazu mal länger auf den Event-Monitor starren...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Hallo Markus,
hallo Jörg,

also der genutzte RAM liegt über viele Wochen/Monate immer im Bereich von 60 bis 80%, demnach liegt es wohl nicht am fehlenden Hauptspeicher.

Ich update Fhem jeden Samstagvormittag, den Server eher selten.

Das Problem an sich ist ja nicht existentiell, und gleichzeitig habe ich keine Idee, wo ich ansetzen könnte.

autoremove, meinst du das: sudo geht autoremove? Ja, das mach ich regelmäßig.

Count: 204 devices for devspec NTFY_ORDER=.+
Count: 139 devices for devspec NOTIFYDEV=.+

"Würde man das globale dns-Attribut checken." --> wie mach ich das?

"Und dazu mal länger auf den Event-Monitor starren..." --> das wird aber eine Herausforderung für mich.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Zitat von: Gisbert am 10 September 2022, 17:17:59
also der genutzte RAM liegt über viele Wochen/Monate immer im Bereich von 60 bis 80%, demnach liegt es wohl nicht am fehlenden Hauptspeicher.
Das kommt mir relativ viel vor, top würde zeigen, wer da grade aktuell was braucht (muss man aber etwas beobachten, um eine Idee zu bekommen, wie das in etwa aussieht, Momentaufnahmen bringen da wenig).

Zitat
Count: 204 devices for devspec NTFY_ORDER=.+
Count: 139 devices for devspec NOTIFYDEV=.+
Na ja, das sieht  eher "sauber" aus. Kannst ja mal versuchen rauszufinden, welche 65 Devices das sind, die "aus der Reihe tanzen". (zwei "list" => vergleichen, ggf. optimieren, wenn einer der anschließenden Eventhandler "viel" zu tun hat (Folgeaktionen))

Zitat
"Würde man das globale dns-Attribut checken." --> wie mach ich das?
help global

Zitat
"Und dazu mal länger auf den Event-Monitor starren..." --> das wird aber eine Herausforderung für mich.
Damit kannst du ein Gefühl dafür bekommst, was so alles passiert. Wenn es "nur so durchrauscht", ist was faul, wenn gar nichts passiert, ist es komisch. Dann würde ich mir die vornehmen, die viele/häufige Events haben. Und die halt nach und nach abarbeiten; vermutlich ergeben sich gewisse Muster, die man übertragen kann, wenn man mal das erste von diesem Typ im Griff hat.
Aber Achtung: wenn viele Readings im "bulk-Modus" aktualisiert werden, ist das Problem deutlich kleiner wie man vermuten würde (Beispiel: Module, die JSON-Blobs auspacken müssen, erzeugen zwar für jeden Datenpunkt im JSON eine Zeile, es ist aber nur jeweils eine "Event-loop" pro Blob)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Hallo Jörg,

bei RAM sieht es so aus:
Unifi: 25-35%
Fhem: 10-20% (allerhöchsten)
Alles andere im kleinstelligen Prozentbereich, oder darunter

Event-Monitor: es rauscht eher vorbei, als dass es langsam zugeht. Für einen kurzen Moment steht das Bild, dann rauscht eine Handy-große Seite durch, kurzer Stopp usw.

Ich benutze ja noch MQTT-Devices, kann es daran liegen? Ich hab sehr viele davon, die im 1- bis 5-minütigem Abstand viel senden. Da ich mit Rhasspy MQTT2 benutze, hab ich noch mehr Bammel den Umstieg auf MQTT2 durchzuführen. Das Senden geht aber von den physischen Devices aus; dann sollte es doch egal sein, was ich in Fhem mache, oder?

Ich kann ja Mal versuchen alle Devices in der Häufigkeit zu halbieren und dann beobachte, wie häufig Fhem neustartet und wie sich Freezemon verhält.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Zitat von: Gisbert am 10 September 2022, 18:51:29
bei RAM sieht es so aus:
Unifi: 25-35%
Fhem: 10-20% (allerhöchsten)
Alles andere im kleinstelligen Prozentbereich, oder darunter
Das ist dann m.E. eher unauffällig, zumal man da in der Regel nicht sieht, wie viel vom _reservierten RAM_ auch tatsächlich genutzt wird.

Die zugehörigen Prozessorlasten?

Zitat
Event-Monitor: es rauscht eher vorbei, als dass es langsam zugeht. Für einen kurzen Moment steht das Bild, dann rauscht eine Handy-große Seite durch, kurzer Stopp usw.
Das klingt zumindest auf den ersten Eindruck nicht optimal, aber wie ich bereits versucht habe zu erklären, muss das nicht unbedingt auch eine hohe Last bedeuten, Bulk oder nicht, das ist eine der Fragen...

Zitat
Ich benutze ja noch MQTT-Devices, kann es daran liegen? Ich hab sehr viele davon, die im 1- bis 5-minütigem Abstand viel senden.
Viel ist relativ. Wie bereits angesprochen: Zieh dir eines raus und schau mal, was bei diesem einen Device in Summe passiert, wie es reinkommt, und was du davon wirklich brauchst

Zitat
Da ich mit Rhasspy MQTT2 benutze, hab ich noch mehr Bammel den Umstieg auf MQTT2 durchzuführen.
Diese Argumentation kann ich nicht nachvollziehen. Ich unterstelle, du nutzt den Rhasspy-internen Server?
Aber selbst wenn nicht: Man kann notfalls auch zwei MQTT-Server parallel betreiben, alles kein großes Problem. Nur den, der für Rhasspy genutzt wird, den sollte man nicht auch für FHEM benutzen.

Zitat
Das Senden geht aber von den physischen Devices aus; dann sollte es doch egal sein, was ich in Fhem mache, oder?
Es ist definitv nicht egal, was du in FHEM machst, selbst wenn du das physische Device selbst nicht beeinflussen kannst - die Auswertung in FHEM kannst du sehr wohl beeinflussen. Man kann bestimmte Topics nicht abonnieren, und v.a. kann man "event-on-change-reading" (&Co) einsetzen, um eingehende Infos nach "wichtig" und "unwichtig" zu sortieren...

Zitat
Ich kann ja Mal versuchen alle Devices in der Häufigkeit zu halbieren und dann beobachte, wie häufig Fhem neustartet und wie sich Freezemon verhält.
Bevor du anfängst rumzuflashen solltest du m.E. die Stellschrauben in FHEM besser kennen.

Das globale Attribut hast du gefunden?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Hallo Jörg,

die Prozessorlasten liegen bei höchstens 10%.

Ich versuche in Fhem dann nur das zu subskribieren, was ich auch tatsächlich benötige; das ist sicher ordentlich was dabei, was weg kann. Gleichzeitig werde ich event-on-change-reading systematischer nutzen; bei älteren Devices gibt es auch da was zu holen.

help global liefert das bei mir, ich weiß aber nicht, was ich damit anstellen kann:

Internal command: global
global
The global device is used to set different global attributes. It will be automatically defined, it cannot be deleted or renamed and has no set or get parameters

Define
N/A

Set
N/A

Get
N/A

Internals
init_errors
contains configuration errors and security issues collected at FHEM startup.


Attributes
altitude
Specifies the mean sea level in meters. Default is 0.

archivedir
archivecmd
nrarchive
archivesort
archivesort may be set to the (default) alphanum or timestamp, and specifies how the last files are computed for the nrarchive attribute.

autoload_undefined_devices
If set, automatically load the corresponding module when a message of this type is received. This is used by the autocreate device, to automatically create a FHEM device upon receiving a corresponding message.

autosave
enable some modules to automatically trigger save after a configuration change, e.g. after a new device was created. Default is 1 (true), you can deactivate this feature by setting the value to 0. Configration errors at startup automatically deactivate this value.
backupcmd
You could pass the backup to your own command / script by using this attribute. If this attribute is specified, then it will be started as a shell command and passes a space separated list of files / directories as one argument to the command, like e.g.:
"/etc/fhem.cfg /var/log/fhem/fhem.save /usr/share/fhem/contrib /usr/share/fhem/FHEM /usr/share/fhem/foo /usr/share/fhem/foobar /usr/share/fhem/www"
Note: Your command / script has to return the string "backup done" or everything else to report errors, to work properly with update!
This Attribute is used by the backup command.
Example:
attr global backupcmd /usr/local/bin/myBackupScript.sh

backupdir
A folder to store the compressed backup file. This Attribute is used by the backup command.
Example:
attr global backupdir /Volumes/BigHD

backupsymlink
If this attribute is set to everything else as "no", the archive command tar will support symlinks in your backup. Otherwise, if this attribute is set to "no" symlinks are ignored by tar. This Attribute is used by the backup command.
Example:
attr global backupsymlink yes

blockingCallMax
Limit the number of parallel running processes started by the BlockingCall FHEM helper routine. Useful on limited hardware, default is 32. If the limit is reached, further calls are delayed.

configfile
Contains the name of the FHEM configuration file. If save is called without argument, then the output will be written to this file.

commandref
If set to "full", then a full commandref will be generated after each update. If set to modular (default since FHEM 6.1), there is only a short description at the beginning, and the module documentation is loaded from FHEM dynamically.

disableFeatures
comma separated list of values. Currently following values are recognized:
attrTemplate: to avoid loading the AttrTemplates (which currently consumes about 1MB of memory and needs some seconds to load on a slow hardware)
securityCheck: to avoid checking if each Server port is secured by password. May make sense to avoid warnings, if you know it better.

dnsHostsFile
If dnsServer is set, check the contents of the file specified as argument. To use the system hosts file, set it to /etc/hosts on Linux/Unix/OSX and C:\windows\system32\drivers\etc\hosts on Windows. Note: only IPv4 is supported.

dnsServer
Contains the IP address of the DNS Server. If some of the modules or user code calls the HttpUtils_NonblockingGet function, and this attribute is set, then FHEM specific nonblocking code will be used to resolve the given address. If this attribute is not set, the blocking OS implementation (inet_aton and gethostbyname) will be used.

encoding
Set the internal encoding used for storing strings. Possible values: bytestream (default) and unicode.
Notes:
Since not all modules were checked, if they work correctly with the internal unicode encoding, this feature is experimental.
Changing the attribute value triggers a save and a shutdown restart

featurelevel
Enable/disable old or new features, based on FHEM version. E.g. the $value hash for notify is only set for featurelevel up to 5.6, as it is deprecated, use the Value() function instead.

holiday2we
If this attribute is set, then the $we variable will be true, if it is either saturday/sunday, or the value of the holiday variable referenced by this attribute is not none.
If it is a comma separated list, then it is true, if one of the referenced entities is not none.
Example:
attr global holiday2we he
Note: if one of the elements in the list is named weekEnd, then the check for saturday/sunday is skipped If the name is noWeekEnd, and its Value is not none, than $we is 0.

httpcompress
the HttpUtils module is used by a lot of FHEM modules, and enables compression by default. Set httpcompress to 0 to disable this feature.

ignoreRegexp
Do not log messages matching the value into the FHEM log. Note: the usual ^ and $ will be appended to the regexp, like in notify or FileLog.

keyFileName
FHEM modules store passwords and unique IDs in the file FHEM/FhemUtils/uniqueID. In order to start multiple FHEM instances from the same directory, you may set this attribute, whose value will appended to FHEM/FhemUtils/

latitude
Used e.g. by SUNRISE_EL to calculate sunset/sunrise.
Default is Frankfurt am Main, Germany (50.112).

longitude
Used e.g. by SUNRISE_EL to calculate sunset/sunrise.
Default is Frankfurt am Main, Germany (8.686).

logdir
If set, the %L attribute in the logfile attribute (or in the FileLog modules file definition) is replaced wth the value of the attribute. Note: changing the value won't result in moving the files and may cause other problems.

logfile
Specify the logfile to write. You can use "-" for stdout, in this case the server won't background itself.
The logfile name can also take wildcards for easier logfile rotation, see the FileLog section. Just apply the archivecmd / archivedir / nrarchive attributes to the global device as you would do for a FileLog device.
You can access the current name of the logfile with { $currlogfile }.

maxChangeLog
FHEM stores the structural change history which is displayed by "save ?" or in FHEMWEB by clicking on the red question mark. By default this list is limited to 10 entries, this attribute changes the limit.

maxShutdownDelay
Some modules need some time at shutdown to finish the cleanup, but FHEM restricts the delay to 10 seconds. Use this attribute to modify the maximum delay.

modpath
Specify the path to the modules directory FHEM. The path does not contain the directory FHEM. Upon setting the attribute, the directory will be scanned for filenames of the form NN_<NAME>.pm, and make them available for device definition under <NAME>. If the first device of type <NAME> is defined, the module will be loaded, and its function with the name <NAME>_Initialize will be called. Exception to this rule are modules with NN=99, these are considered to be utility modules containing only perl helper functions, they are loaded at startup (i.e. modpath attribute definition time).

motd
Message Of The Day. Displayed on the homescreen of the FHEMWEB package, or directly after the telnet logon, before displaying the fhem> prompt. In addition, the content of the internal value init_errors will be displayed. To avoid displaying messages set its value to none.

mseclog
If set, the timestamp in the logfile will contain a millisecond part.

nofork
If set and the logfile is not "-", do not try to background. Needed on some Fritzbox installations, and it will be set automatically for Windows.

perlSyntaxCheck
by setting the global attribute perlSyntaxCheck, a syntax check will be executed upon definition or modification, if the command is perl and FHEM is already started.

pidfilename
Write the process id of the perl process to the specified file. The server runs as a daemon, and some distributions would like to check by the pid if we are still running. The file will be deleted upon shutdown.

proxy
IP:PORT of the proxy server to be used by HttpUtils.

proxyAuth
Base64 encoded username:password

proxyExclude
regexp for hosts to exclude when using a proxy

restoreDirs
update saves each file before overwriting it with the new version from the Web. For this purpose update creates a directory restoreDir/update in the global modpath directory, then a subdirectory with the current date, where the old version of the currently replaced file is stored. The default value of this attribute is 3, meaning that 3 old versions (i.e. date-directories) are kept, and the older ones are deleted.
fhem.cfg and fhem.state will be also copied with this method before executing save into restoreDir/save/YYYY-MM-DD. To restore the files, you can use the restore FHEM command.

If the attribute is set to 0, the feature is deactivated.

sendStatistics
statefile
Set the filename where the state and certain at information will be saved before shutdown. If it is not specified, then no information will be saved.

title
useInet6
try to use IPv6 in HttpUtils for communication. If the server does not have an IPv6 address, fall back to IPv4. Note: IO::Socket::INET6 is required.

userattr
A space separated list which contains the names of additional attributes for all devices. Without specifying them you will not be able to set them (in order to prevent typos).
userattr can also specified for other devices, in this case these additional attribute names are only valid for this device.

dupTimeout
Define the timeout for which 2 identical events from two different receiver are considered a duplicate. Default is 0.5 seconds.

showInternalValues
Show data used for internal computations. If the name of an internal value, reading or attribute starts with dot (.), then it is normally hidden, and will only be visible, if this attribute is set to 1. The attribute is checked by the list command, by the FHEMWEB room overview and by xmllist.

sslVersion
Specifies the accepted cryptography algorithms by all modules using the TcpServices helper module. The current default TLSv12:!SSLv3 is thought to be more secure than the previously used SSLv23:!SSLv3:!SSLv2, but it causes problems with some not updated web services.

stacktrace
if set (to 1), dump a stacktrace to the log for each "PERL WARNING".

restartDelay
set the delay for shutdown restart, default is 2 (seconds).


Events:
INITIALIZED
after initialization is finished.
REREADCFG
after the configuration is reread.
SAVE
before the configuration is saved.
SHUTDOWN
before FHEM is shut down.
DEFINED <devname>
after a device is defined.
DELETED <devname>
after a device was deleted.
RENAMED <old> <new>
after a device was renamed.
UNDEFINED <defspec>
upon reception of a message for an undefined device.
MODIFIED <defspec>
after a device modification.
UPDATE
after an update is completed.
CANNOT_FORK
if BlockingCall encounters this problem.


Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Wernieman

#8
Im Gegensatz zu meinen Vorrednern sehe ich doch ein gewisses RAM Problem bei Dir. Du hat in dem Beispiel 4h die Maschine laufen und es wird schon "reichlich" SWAP verwendet. Da eine SSD deutlich langsamer als ein RAM ist (Faktor 1000?), sollte er eigentlich erst viel später in die Richtung gehen müssen. Auch wenn Du zusätzlich schreibst, das Du 60-80% RAM (60% kein Problem,  80% dagegen schon nicht mehr so "nett"), würde ich in die Richtung mal optimieren.

Und bevor Du jetzt direkt Hardware kaufen, ist das Stichwort "swappines". siehe z.B. https://ubunlog.com/de/swappiness-como-ajustar-el-uso-de-la-memoria-virtual/ oder  https://wiki.ubuntuusers.de/Swap/
Ich würde den mal auf ~20 setzen. Normalerweise steht er bei 60.

Zusätzlich:
Wobei die Hinweise der Eventreduzierung eine große Bedeutung für Dich haben. Brauchst Du wirklich jede (so schriebst Du) Minute Werten von einigen MQTT Device? Wenn man das z.B. auf 2 Minuten reduziert, erfolgt schon eine Reduzierung bei den Device um den Faktor 2.

Ich kenne mich mit Unifi nicht aus, aber wirklich 25-35% Speicher?

Hast Du einen Druckserver auf der Maschine (z.B. CUPS)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

MadMax-FHEM

#9
Zitat von: Wernieman am 10 September 2022, 21:18:53
Ich kenne mich mit Unifi nicht aus, aber wirklich 25-35% Speicher?

Ich weiß jetzt nicht, wie viel Speicher steckt.
Bei mir läuft Unifi-Controller auf einem PI4 4GB (zusammen mit anderen Dingen), fhem läuft "alleine" :)

Ich habe laut top einen Verbrauch von Unifi plus MongoDB von 400MB - (aktuell) 670MB...

Wächst langsam an und wenn ich dann mal boote (aber eher sehr selten), dann fängt es wieder bei so 300/400MB an...

EDIT: hast du das Standard systemd-Script oder angepasst? Ich hatte ja eine Abhängigkeit zu einem anderen Service (deCONZ) "reingemurkst" und mich gewundert, warum fhem ab und an neu gestartet wurde (war eine neuere Installation bei einem Freund mit deCONZ und fhem auf einem PI)...
...bis ich dann merkte, dass wohl deCONZ öfter mal neu startet und damit (dank mir ;)  ) auch fhem...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Gisbert

Hallo Wernieman,

Fhem lief zu diesem Zeitpunkt 4 Stunden, der Server ca. 6-8 Wochen.

Ich hab gestern Abend (spät) den Server neu gestartet mit dem empfohlenen Wert für "swappiness" (vorher). Bis jetzt ist die Swap-Datei leer. Unifi gönnt sich nach wie vor mit 2 Prozessen 25% RAM.

Die Reduzierung der Events steht auf der to-do-Liste, ganz eindeutig. Einen Druckerserver hab ich nicht.

Hallo Joachim,
ZitatStandard systemd-Script oder angepasst?
das kann ich dir gar nicht sagen, ich hab nach Anleitung gehandelt, mit anderen Worten ich bin Laie. Was muss ich an Informationen, Daten liefern, dass du dir einen Überblick verschaffen kannst?

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

MadMax-FHEM

Also wenn du nie in der Datei: /etc/systemd/system/fhem.service editiert hast, dann wird fhem wohl mit der Standarddatei gesteuert...

Ansonsten halt den Inhalt dieser Datei posten ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Gisbert

Hallo Joachim,

an der Datei fhem.service war ich nie dran.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Gisbert

Hallo zusammen,

kurzes update.

Ich hab bei den allermeisten Devices (hauptsächlich MQTT-Devices) das update-Intervall höher gesetzt und gleichzeitig konsequent überall event-on-change-reading .* gesetzt. Damit werden die Events gefühlt auf die Hälfte reduziert.

Die Swap-Datei ist mittlerweile bei 12% angekommen. Ich werde das weiter beobachten.

Da ich jeden Samstag ein automatisiertes Fhem-Update fahre, was einen Neustart von Fhem beinhaltet, werde ich über einen Erfahrungsschatz von einer Woche nicht hinauskommen. Ich werde über eine längere Zeit beobachten müssen, ob unter der Woche dann noch ein Neustart stattfindet.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

MadMax-FHEM

Zitat von: Gisbert am 12 September 2022, 12:43:44
Ich hab bei den allermeisten Devices (hauptsächlich MQTT-Devices) das update-Intervall höher gesetzt und gleichzeitig konsequent überall event-on-change-reading .* gesetzt. Damit werden die Events gefühlt auf die Hälfte reduziert.

Eine gute Hilfe hierfür ist auch DOIF-Tools, das kann eine Statistik über Events und Events/Device usw. erzeugen.
Damit kann man sehr einfach sehen, was die "schlimmen Devices" sind (viele Events/Zeit).

Was mir noch einfällt: watchdog. Hast du einen eingerichtet? Also ich meine jetzt "System-Watchdog" nicht einen Watchdog/Modul/Device in fhem... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)