Cannot fork: Cannot allocate memory | BlockingInformParent

[gloob]

Wie greift tabletui bei Dir zu? Ich habe nginx dafür genommen. Hast du httpsrv?

Die TabletUI Webseite öffne ich auf einem Amazon Fire HD 8.
TabletUI läuft als:

Code Auswählen Erweitern

define TABLETUI HTTPSRV ftui/ ./www/tablet/ Tablet-UI

Edit:
30.08.2019 16:15 So sieht aktuell mein Speicherverlauf aus vor dem Abschalten der TableUI anzeige.

[Hardlife]

Ich habe etwas recherchiert. Zeitlich könnte eine Anpassung an FHEMWEB passen. Sollte also in den nächsten 60 min der Speicherverbrauch nicht weiter ansteigen werde ich in diese Richtung weiter schauen. Natürlich wird dies nun kein Problem von FHEMWEB alleine. Ich habe da meine 3 Jahre alte TabletUI Installation im Auge. Eventuell hat die Probleme mit dem neuen FHEMWEB. Aber das muss ich mir genauer anschauen.
Aktuell kann ich lediglich meine Beobachtungen kund tun.

Wann wurde denn FHEMWEB geändert? Und was?

Ich frage deshalb, weil ich seit Jänner diesen Jahres auch zu den Gepeinigten gehöre 
- Ich habe hier ein Backup-Image vom 12.10.2018 - damit hatte ich keinerlei Probleme.
- Im Jänner 2019 habe ich dann upgedatet (ich mache nicht jede Woche ein Update)
- seither habe ich den Speicheranstieg, obwohl sich an der FHEM-Konfiguration nichts geändert hat. Alle 19 Stunden resetted FHEM
- Auch am Unterbau (damals  Raspbian-Jessie) hat sich nichts geändert
- ich habe dann verschiedene Perl-Versionen versucht und bin mittlerweile auf Raspbian-Buster. Leider ohne Erfolg

In meiner Wohnung hängen 6 Tablets, welche immer mit FHEMWEB verbunden sind. Auch 3 Handys greifen sporadisch auf FHEMWEB zu.
FHEMWEB wird über einen Apache-Proxy nach außen geleitet und der Zugriff erfolgt über WebViewControl...
Da die ganze Wohnung von FHEM gesteuert wird und die Interface-Tablet benötigt werden, kann ich leider nicht einfach zu Testen die FHEMWEB´s abschalten...

Grüße,
Hardlife

[CoolTux]

Ich möchte noch mal explizit erwähnen daß es bei mir nicht am FHEMWEB lag. Es waren zu dem Zeitpunkt nur meine Beobachtungen.
Aktuell ist es so das es anscheinend mein HAProxy ist der Abfragen in irgendeiner Form an FHEMWEB macht. Genaueres muss ich dann erst noch schauen.
An ein verschulden von FHEMWEB denke ich nicht!!!

[gloob]

Ein Deaktivieren der FTUI GUI hat auch keinen Erfolg gebracht

[rudolfkoenig]

Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

[Hardlife]

Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

Danke für den Tipp. Das werde ich gleich mal versuchen.
Da bei mir der Speicher innerhalb eines Tages ca. um 500MB wächst, kann ich morgen Genauers sagen...

[towag]

Ich kann ebenfalls bestätigen, dass ein Abdrehen aller remote Browser (FTUI) keine Auswirkung auf den Speicherverbrauch gezeigt hat. Der Raspberry selbst hat keine GUI Komponenten

[Hardlife]

Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

Ich habe mich mal dran versucht...
Und sehe nun auch den Speicheranstieg sehr deutlich.
Das memdump habe ich auch gemacht und mir das ganze in eine Textdatei konvertiert.

Für die paar Stunden ein ganz schön satter Anstieg:

Code Auswählen Erweitern


BEFORE:
01e62000-06264000 rw-p 00000000 00:00 0          [heap]
Size:              69640 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:               69488 kB
Pss:               69488 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:     69488 kB
Referenced:        69488 kB
Anonymous:         69488 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB

AFTER:
01e62000-0ce0b000 rw-p 00000000 00:00 0          [heap]
Size:             179876 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              179580 kB
Pss:               69999 kB
Shared_Clean:          0 kB
Shared_Dirty:     164384 kB
Private_Clean:         0 kB
Private_Dirty:     15196 kB
Referenced:       179580 kB
Anonymous:        179580 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB

Tja, das memdump ist leider 175MB groß und die daraus erzeugte Textdatei 52MB!

Da sehe ich als Laie leider gar nichts drin.
Ich sehe sehr wohl meine Geräte und die Events und so, aber das ist einfach zu umfangreich.
Wonach sollte man da suchen?

Vielen Dank,
Hardlife

[rudolfkoenig]

In memdump 0x06264000 - 0x0ce0b000 muessten nur die neu hinzugekommenen Texte vorhanden sein. Was sieht man da?

[Hardlife]

Mann Mann Mann 

War aber auch logisch... Und ich habe den ganzen Speicherbereich ausgelesen...
Ich mach noch eine Messung und messe vom Ende des ersten auf das Ende des zweiten Speicherbereichs.

Danke für die Unterstützung,
Hardlife

[Hardlife]

So, ich habe nun einen zweiten Dump angefertigt - Messzeitraum habe ich kürzer gewählt und die Memory-Bereiche habe ich angepasst
-> die neue Datei hat leider 15MB 

Also habe ich einen dritten Dump angefertigt - Messzeitraum ein paar Minuten
-> diese Datei hat "nur" 1,4MB

Auch habe ich mir beide Text-Auszüge angesehen, stoße mangels Tiefenkenntnissen aber wieder an meine Grenzen... 
Ich "denke", dass ich immer wieder den Aufruf meines in FHEMWEB angezeigten Raummenüs in der 1,4MB-Datei erkenne.
(wie beschrieben, sind bei mir ja auch 6 Tablets ständig mit FHEM verbunden)
Kann aber auch sein, daß ich gar nichts sehe und meine Messergebnisse gar nicht aussagekräftig sind... 

In der 15MB-Datei ist noch etwas mehr zu sehen...
(die Datei hänge ich mal komprimiert an)

Vielleicht ist jemand so nett und sieht mit seinem fachkundigem Auge mal drüber?
Ich trete hier wie gesagt leider auf der Stelle...


LG,
Hardlife

[rudolfkoenig]

Danke fuer den Dump.

Nach studieren der Daten und Quellcode suchen meine ich ein Speicherloch aus FHEMWEB entfernt zu haben, was auftritt falls eine Raumuebersicht mit "FW_atPageEnd" Modulen aufgerufen wird (readingsGroup, readingsHistory, FB_CALLLIST, weblink, weekprofile). Auch SVG gehoert dazu, falls plotfork oder plotEmbed nicht gesetzt ist.
Ursache: in diesen Faellen wurden Daten aus einer Modul-Lokalen-Variable nicht entfernt.

Workaround: reload 01_FHEMWEB duerfte das Problem (temporaer) beheben, und Speicher freigeben, das sieht man in der "ps -elf" Ausgabe sofort.

Bei der Fehlersuche habe ich leider feststellen muessen, dass fhemdebug memusage solche Variablen nicht sieht, deswegen ist die Aussagekraft begrenzter, als ich es dachte.

[gloob]

Danke fuer den Dump.

Nach studieren der Daten und Quellcode suchen meine ich ein Speicherloch aus FHEMWEB entfernt zu haben, was auftritt falls eine Raumuebersicht mit "FW_atPageEnd" Modulen aufgerufen wird (readingsGroup, readingsHistory, FB_CALLLIST, weblink, weekprofile). Auch SVG gehoert dazu, falls plotfork oder plotEmbed nicht gesetzt ist.
Ursache: in diesen Faellen wurden Daten aus einer Modul-Lokalen-Variable nicht entfernt.

Workaround: reload 01_FHEMWEB duerfte das Problem (temporaer) beheben, und Speicher freigeben, das sieht man in der "ps -elf" Ausgabe sofort.

Bei der Fehlersuche habe ich leider feststellen muessen, dass fhemdebug memusage solche Variablen nicht sieht, deswegen ist die Aussagekraft begrenzter, als ich es dachte.

Das klingt ja nach einer vielversprechenden Lösung, super Arbeit.
Ab morgen dann im Update?

[Maista]

Ja

https://forum.fhem.de/index.php/topic,103416.0.html


Gruss
Gerd

[Hardlife]

Danke fuer den Dump.

Keine Ursache, immer gern. Solange ich halbwegs durchsteige, bin ich zu allen Schandtaten bereit

Ich möchte mich im Gegenzug aber für all die Mühe und Arbeit bedanken, die Du in dieses echt endgeile Projekt steckst.
Ist sicher nicht immer einfach und lustig und darum VIELEN DANK fürs Erschaffen dieser tollen Smarthome-Basis

LG,
Hardlife