Cannot fork: Cannot allocate memory | BlockingInformParent

[popy]

defmod sysmon SYSMON 1
attr sysmon event-min-interval cpu_temp:600,cpu_temp_avg:600,cpu_freq:600,cpu_freq_stat:600,ram:600,eth0_diff:600,fs_root.*:600
attr sysmon event-on-change-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,cpu_freq_stat,ram,eth0_diff,fs_root.*
attr sysmon filesystems fs_boot:/boot:Boot,fs_root:/:Root
attr sysmon network-interfaces eth0:eth0:Ethernet
attr sysmon room System

defmod Sysmon.filelog FileLog ./log/sysmon-%Y-%W.log sysmon
attr Sysmon.filelog icon edit_settings
attr Sysmon.filelog nrarchive 4
attr Sysmon.filelog room Log

defmod Sysmon_RAM.svg SVG Sysmon.filelog:SM_RAM:CURRENT
attr Sysmon_RAM.svg label "RAM - Gesamt: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr Sysmon_RAM.svg room System

Danke Vielmals, jetzt monitore ich auch meinen RAM und schau mal wie der Anstieg ist.

Hier noch der memusage nach ~07h, mit ps sehe ich dass der Prozess auf 10% angewachsen ist.

Code Auswählen Erweitern


fhemdebug memusage 03.01.2019 12:06:
Nach uptime: 07:27:33

   1. defs                            1840578
   2. modules                          614767
   3. defs::WZ_unifi_controller        569051
   4. modules::eventTypes              370353
   5. modules::eventTypes::ldata       369291
   6. defs::WZ_unifi_controller::READINGS   302340
   7. attr                             156017
   8. defs::WZ_unifi_controller::clients   133130
   9. defs::WZ_unifi_controller::accespoints   118054
  10. defs::BAD_Waschmaschine           62574
  11. defs::BAD_Trockner                62375
  12. defs::KUECHE_Spuelmaschine        58383
  13. defs::BAD_Waschmaschine::READINGS    56670
  14. defs::BAD_Trockner::READINGS      56636
  15. defs::KUECHE_Spuelmaschine::READINGS    52709
  16. defs::sysmon                      47260
  17. defs::Alexas                      46511
  18. defs::Switch_Wohnzimmer__150W_    42491
  19. POSIX::                           37247
  20. defs::myTL                        35354
  21. defs::Alexas::helper              34063
  22. defs::sysmon::READINGS            30093
  23. defs::Switch_Arbeitsstation       29787
  24. defs::ECHO_Kueche                 27335
  25. defs::ECHO_Wohnzimmer             24296
  26. defs::ECHO_Badezimmer             24294
  27. defs::Switch_Schlafzimmer         24212
  28. defs::Switch_Wohnzimmer__PoE_passive_    24137
  29. defs::ECHO_Julians_Zimmer         24135
  30. defs::Switch_Wohnzimmer__150W_::READINGS    23770
  31. defs::ECHO_Schlafzimmer           22688
  32. defs::WZ_unifi_controller::accespoints::5b4ccd9c93c42315e05aaf31    22635
  33. defs::WZ_unifi_controller::accespoints::5b4cc95a93c42315e05aac50    22523
  34. defs::Kodi_SZ                     22225
  35. defs::Kodi_SZ::READINGS           20911
  36. modules::eventTypes::ldata::ECHO_Julians_Zimmer    20353
  37. modules::eventTypes::ldata::ECHO_Kueche    20034
  38. modules::eventTypes::ldata::ECHO_Badezimmer    19866
  39. modules::eventTypes::ldata::ECHO_Wohnzimmer    19531
  40. modules::eventTypes::ldata::WZ_unifi_controller    19046
  41. modules::eventTypes::ldata::Kodi_SZ    18967
  42. modules::eventTypes::ldata::Kodi_WZ    18847
  43. modules::IT                       18487
  44. defs::ECHO_Kueche::READINGS       18438
  45. modules::eventTypes::ldata::BAD_Waschmaschine    18309
  46. modules::eventTypes::ldata::BAD_Trockner    18222
  47. modules::eventTypes::ldata::KUECHE_Spuelmaschine    18155
  48. defs::Kodi_WZ                     17708
  49. modules::eventTypes::ldata::CUL433    17431
  50. defs::Switch_Wohnzimmer__150W_::usw    17121


Kann mir Bitte jemand helfen das obige zu deuten?

Hier meine Fragen:
Würdet ihr den Umstieg auf die ältere Perl Version Vorsorglich empfehlen oder sollte ich anschauen was RAM Verbraucht?
Ist "apptime" ein Potentieller SPeicher fresser wenn ich nachher kein shutdown restart mache?

Danke
pOpY

[iice64]

Bei mir liegt es eindeutig an der perl version 5.24.1 
Nachdem ich mit perlbrew zur alten version 5.20.3 zurück gegangen bin, läuft der Speicher nicht mehr voll. 

[popy]

Bei mir liegt es eindeutig an der perl version 5.24.1 
Nachdem ich mit perlbrew zur alten version 5.20.3 zurück gegangen bin, läuft der Speicher nicht mehr voll. 

Ok danke, ich glaube ich mache das auch.
Möchte zuerst noch ein Diagram sehen wo er vollläuft und dann werde ich zurüchsteigen.

Wie schaut es eigentlich bei einem apt-get update aus? Bleibt da die perlbrew version installiert und aktiviert?

pOpY

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[iice64]

Mit diesem Script kann mann sich eine fertig kompilierte für den Raspberry Pi (armv7l-linux) perl-5.20.3 und perlbrew installieren.
https://www.dropbox.com/s/926car881dvhrau/install-perlbrew-from-tar.sh?dl=1
(wie immer ohne Gewähr)

Dann noch /etc/init.d/fhem anpassen. Änderungen sind fett.

#!/bin/bash
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

export PERLBREW_ROOT=/opt/perlbrew
source /opt/perlbrew/etc/bashrc
perlbrew use perl-5.20.3

set -e
cd /opt/fhem
port=7072

[iice64]

Wie schaut es eigentlich bei einem apt-get update aus? Bleibt da die perlbrew version installiert und aktiviert?

Ja, denn die perl-5.20.3 ist zusätzlich zum system perl installiert.
Solange perlbrew use perl-5.20.3 in der /etc/init.d/fhem drin ist.

[popy]

Ja, denn die perl-5.20.3 ist zusätzlich zum system perl installiert.
Solange perlbrew use perl-5.20.3 in der /etc/init.d/fhem drin ist.

Danke für die ganzen Infos.
Habe das jetzt beobachtet und 3x den Speicherverbrauch angesehen, mit folgendem Ergebnis:

Code Auswählen Erweitern


03.01.2019 04:41: fhem     27616 21.5  5.2  55184 49932 ?        R    04:40   0:14 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 11:52: fhem     27616 14.6 10.7 107928 101972 ?       S    04:40  63:20 /usr/bin/perl fhem.pl fhem.cfg
03.01.2019 14:42: fhem     27616 15.3 12.2 122124 116136 ?       S    04:40  92:17 /usr/bin/perl fhem.pl fhem.cfg


Das wäre ein Anstieg von:

Code Auswählen Erweitern


0,71% / h = 6,86 MB / h


Sprich, in etwas mehr als 3 Tagen wäre der RAM wieder voll. Ich bin mir jetzt nicht sicher ob ich gleich das ältere Perl installieren soll.
Oder ich noch andere Analysen machen kann (ev. welches Modul sich den Speicher gönnt).
Mit "fhemdebug memusage" haben sich werte jetzt in ~3h wie folgt verändert:

Code Auswählen Erweitern


   1. defs                            1840578 -> 1855907
   2. modules                          614767 -> 614831
   3. defs::WZ_unifi_controller        569051 -> 573265


Ich vermute es sind bytes (da, wenn kB der PI nicht so viel RAM hat) wären das ja "nur" 15329 bytes in 3h (bei den defs, die anderen sind vernachlässigbar).
Das ist weit weg von den 6,86 MB / h die der fhem Prozess sich gönnt (mit ps -aux).

Hast du noch Ideen wo ich noch schauen kann was den Speicher verbrät?
Wie ist der Speicherverbrauch mit ps -aux bei dir nach ein paar Stunden Laufzeit?

Danke Vielmals für Deine Unterstützung
pOpY

[iice64]

Sprich, in etwas mehr als 3 Tagen wäre der RAM wieder voll. Ich bin mir jetzt nicht sicher ob ich gleich das ältere Perl installieren soll.

Da wie ich vermute, perl-5.24.1 das Speicherleck produziert. Kannst du im fhem nichts feststellen.
Man erkennt es nur am perl Prozess, der sich immer mehr Speicher greift.

Ich würde dir zur perl-5.20.3 raten.

Oder man muss auf das CANNOT_FORK reagieren und fhem neu starten.
Finde ich persönlich unsauber, man weiß ja nie, wann es passiert und welches Ereignis nicht bearbeitet wurde.

defmod cannot_fork.restart.notify notify global:CANNOT_FORK shutdown restart

[rudolfkoenig]

Oder ich noch andere Analysen machen kann (ev. welches Modul sich den Speicher gönnt).

Die Ursache rauszufinden waere schon sinnvoll, und ein Modul zu indentifizieren der erste Schritt.
Es sei denn, irgendwer prueft 5.26, das Problem gibt es da nicht mehr, und wir sind den Spuk demnaechst automatisch los.

[popy]

Die Ursache rauszufinden waere schon sinnvoll, und ein Modul zu indentifizieren der erste Schritt.
Es sei denn, irgendwer prueft 5.26, das Problem gibt es da nicht mehr, und wir sind den Spuk demnaechst automatisch los.

5.26 wurde schon getestet unter Ubuntu, leider ohne Erfolg, Siehe Post: https://forum.fhem.de/index.php/topic,84372.msg846849.html#msg846849
Wenn du mir sagst wie ich draufkomme welches Modul sich den Speicher gönnt kann ich Gerne schauen.
Bei mir gönnt sich perl mit fhem.pl ~7MB RAM pro Stunde.

Das Problem ist dass dies mein (einziges) Produktiv System ist.
Der WAF ist auch schon im Keller  wenn mitten in der Nacht irgendwelche Sachen von selbst schalten weil der RAM aus ist (Notifys sind angesprungen da keine Presence Forks (pings) mehr erstellt werden konnten). Deshalb tendiere ich eher zum alten perl als schnelle Abhilfe.

Bis 18:00 hätte ich noch Zeit  was zu analysieren.

Eine Sache noch: ich habe 2x structs (Siehe erste Posts) die über 300000 in count bei apptime aufscheinen.
Könnte es damit zusammenhängen?
In jeder Struct sind 2x dummys mit gesetztem "event-on.change-reading state", verstehe auch nicht warum, hier die Zeilen von apptime:

    name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
    P_Kueche_All                             structure_Notify                      1167   377045   64699.52     0.17     0.00     0.00 02.01. 20:33:46 HASH(P_Kueche_All); HASH(P_Kueche_Tuer)
    P_Bad_All                                structure_Notify                       515   377045   43336.09     0.11     0.00     0.00 02.01. 18:23:37 HASH(P_Bad_All); HASH(P_Bad_Tuer)


pOpY

[kadettilac89]

Eine Sache noch: ich habe 2x structs (Siehe erste Posts) die über 300000 in count bei apptime aufscheinen.
Könnte es damit zusammenhängen?

Ja, bei mir hat Modul apptime den Ram verschlungen. War bei dir apptime immer aktiv?

Deaktiviere mal apptime und schau ob Ram noch zunimmt. Ohne aktivem apptime ist mein Ram mehr oder weniger stabil. Mit version 5.24.1.

[popy]

Ja, bei mir hat Modul apptime den Ram verschlungen. War bei dir apptime immer aktiv?

Deaktiviere mal apptime und schau ob Ram noch zunimmt. Ohne aktivem apptime ist mein Ram mehr oder weniger stabil. Mit version 5.24.1.

Ja, in dem Fall war apptime aktiv (hatte vergessen shutdown restart zu machen).
Das wusste ich deshalb da bei erster eingabe von "apptime max" im Fehlerfall ich sofort die Ausgabe bekam und nicht "apptime initialized".
Jetzt teste ich aber ohne apptime und der RAM von fhem steigt, derzeit soviel (mit ps -aux):

Code Auswählen Erweitern


Nach 12:40:34 uptime:
0,63% / h
6,1 MB / h


Wieviel ist dass jetzt bei Dir mit 5.24.1.?

Danke
pOpY

[kadettilac89]

Ja, in dem Fall war apptime aktiv (hatte vergessen shutdown restart zu machen).
Das wusste ich deshalb da bei erster eingabe von "apptime max" im Fehlerfall ich sofort die Ausgabe bekam und nicht "apptime initialized".
Jetzt teste ich aber ohne apptime und der RAM von fhem steigt, derzeit soviel (mit ps -aux):

Code Auswählen Erweitern


Nach 12:40:34 uptime:
0,63% / h
6,1 MB / h


Wieviel ist dass jetzt bei Dir?

Danke
pOpY

Code Auswählen Erweitern


USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
fhem     28235  0.7  8.1  96080 62556 ?        S     2018  35:36 /usr/bin/perl fhem.pl fhem.cfg
fhem     28313  0.0  2.6  74240 20472 ?        S     2018   0:29 /usr/bin/perl fhem.pl fhem.cfg


Code Auswählen Erweitern


FHEM up time: 3 days, 05 hours, 36 minutes
System up time: 8 days, 23 hours, 56 minutes


[Damian]

Nach meinen Untersuchungen führen bestimmte, häufige Regex-Abfragen in Perl 5.24 zu memory leak. Diese Perl-Version macht am meisten Probleme.

Mit Active Perl 5.26 war das Problem bei mir nicht mehr aufgetreten.

[popy]

Danke euch allen, werde das RAM Log jetzt bis morgen laufen lassen und dann die Auslastung beurteilen.
Melde mich mit dem Graphen zurück.

[rudolfkoenig]

Wenn du mir sagst wie ich draufkomme welches Modul sich den Speicher gönnt kann ich Gerne schauen.

Ein Modul nach dem Anderen abschalten, und dazwischen pruefen, ob das Problem noch besteht.