Ram läuft voll

[aleks-83]

Ich hänge mich mal dran, da ich ein ähnliches Problem habe.

Mein System befindet sich gerade im Aufbau.

Mein ioBroker läuft in einer Debian Bookworm VM in Hyper-V unter Windows 10.
Dieser VM habe ich dynamischen RAM von 1024 - 12000MB zugewiesen.
Laut Process Explorer nimmt sich die VM auch 12000 MB.
Im ioBroker Info Fenster sehe ich aber dass dem ioBroker nur 895.2 MB zur Verfügung gestellt werden.

[OliverIO]

@aleks-83

hast du denn Probleme?
Evtl hat iobroker/nodeJS auch nur nach soviel RAM gefragt
und würde dann mit steigender Anzahl von Adaptern auch mehr RAM vom Betriebssystem anfordern.
iobroker ist ja nicht das einzige System auf einem Rechner. sollte das Betriebssystem nun allen Applikationen alle4s mal auf Vermutung zuordnen was geht? So läuft das nicht.

Oben siehst du ja das die RAM-Auslastung bei 3.1% liegt.

Das "ähnliche Problem" oben ist, das der tatsächliche RAM-Bedarf schon an das Gesamtverfügbare geht.

[aleks-83]

@oliverio
Beim Starten des ioBroker bekam ich die Meldung dass zu wenig RAM (35MB) frei sei und keine Adapter mehr gestartet werden könnten.
Ich habe jetzt testweise mal mehrere Adapter der Reihe nach gestartet, aber es läuft weiterhin.

EDIT:
Jetzt läuft alles sehr langsam.
Der Info Tab öffnet sich nicht, Er lädt, und lädt, und lädt...
Der Instanzen Tab öffnet nicht und gibt Meldung "Cannot read instances"

[aleks-83]

[Thomas Braun]

@aleks-83

Was spuckt

free -ht --mega

aus?
Vielleicht auch mal die ganze Choose mit

iob diag

anschauen.

[aleks-83]

@thomas-braun sagte in Ram läuft voll:

@aleks-83

Was spuckt

free -ht --mega

aus?

Vielleicht auch mal die ganze Choose mit

iob diag

anschauen.

[Thomas Braun]

@aleks-83

Keine Bildchen von Text, sondern in Codetags eingebettet den Text hier reinkopieren.

[OliverIO]

@d3ltoroxp sagte in Ram läuft voll:

Am 1.3. deaktiviert und am 6.3. wieder aktiviert. Eins alleine. Zudem läuft noch das Batterie Script von dir @Pittini

Ram war paar mal voll. ioBroker geht wieder nicht.

Das ist erst mal nur eine Vermutung, das es an dem Fensterskript liegt?
Es könnte ja sein, das das skript nur das i-tüpfelchen ist.
Ich hab mal das Skript durchgeschaut, ja da werden ein paar async-Funktionen erzeugt und getriggert (on, setInterval). Die haben immer ein Risiko, das es zu Speicherlecks führt.
Da aber das skript mehrfach im Einsatz ist, kann es entweder nur an der Konfiguration liegen oder an einem anderen Adapter/Skript, das diese ausschläge erzeugt.
Ich weiß jetzt nicht von wo diese Grafik ist, aber man sollte erstmal unterscheiden ob dein Problem im javascript-Adapter liegt oder woanders.

iobroker hat da ein paar Datenpunkte, die genau dafür zum monitoren da sind.
wenn du im objekt-browser die expertendarstellung aktivierst, hast du einen neuen top-level datenpunkt system.
da würde ich zunächst mal für diesen punkt die history anschalten
system.host.<deiniobrokername>.mem

dann für den javascriptadapter diese
system.adapter.javascript.0.memHeapTotal
system.adapter.javascript.0.memHeapUsed

für weitere adapter die bei dir unter verdacht stehen dann entsprechend die gleichen

dann lass das mal eine weile laufen, am besten solange bis die situation wieder eingetreten ist.
ich weiß nicht ob es nach einem tag schon soweit ist

es gilt herauszufinden, welcher adapter diese spitzen ram verbrauch auslöst.
meist ist es schon der javascript-adapter.
problem ist, das nur über try and error das konkrete skript herausgefunden werden kann.
dann einfach mal ein verdächtiges skript abschalten und nach gewisser zeit schauen, ob diese spitzen, die man in der grafik sieht wieder auftauchen. so könnte man das problem auf adapter und dann evtl (wenn javascript adapter betroffen ist) auch auf ein konkretes skript eingrenzen.

wenn wir das haben können wir uns weitere maßnahmen anschauen (bspw bei einem skript mehr logmeldungen einbauen um zu sehen, ob da sich irgendwas aufschaukelt was viel ram verbraucht)

kannst du schon sagen, das wenn so eine ram-spitze war und der verbrauch wieder zurückgegangen ist, ob sich das normalisiert hat weil ein prozess abgeschossen wurde? dann kannst du mit dem iob diag skript mal nach den oom ereignissen schauen (out of memory)
darüüber könnten wir auch schauen welcher prozess es wirklich ist. jeder adapter läuft in einem eigenen prozess.

[aleks-83]

@thomas-braun sagte in Ram läuft voll:

@aleks-83

Keine Bildchen von Text, sondern in Codetags eingebettet den Text hier reinkopieren.

Hätte ich ja gemacht, wenn die Zwischenablage der VM funktionieren würde.
Das tut sie aber noch nicht.

[bahnuhr]

@aleks-83
F5 drücken, dann gehts

[aleks-83]

@bahnuhr
Bei mir ändert F5 nichts.

Ich denke dass HyperV den RAM zu langsam dynamisch zuweist.
In der Console von Debian habe ich auch Fehlermeldungen gesehen die auf zu wenig RAM deuten. Leider kann ich sie nicht mehr reproduzieren.

Ich installiere gerade Debian unter VirtualBox, vielleicht läuft es damit besser.
Melde mich

[aleks-83]

Unter VirtualBox sieht es besser aus.
Dort werden 9,5GB angezeigt und 4 CPUs.
Unter HyperV war es auch nur 1 CPU obwohl ich 4 angegeben hatte.

Der Wert unter RAM steht jetzt bei 92,3%.
In der HyperV VM stand er bei 3,1%.
Der Wert besagt offenbar wieviel RAM noch frei ist, und nicht wieviel verwendet wird.

[Thomas Braun]

@aleks-83

free -ht --mega

anschauen.

[aleks-83]

@thomas-braun

Speicher:
Gesamt: 10G
Genutzt: 999M
Frei: 9.1G

[Thomas Braun]

@aleks-83

Die Ausgabe sieht anders aus. Aus dem Terminal kopieren.

[aleks-83]

@thomas-braun
Wenn ich die Zwischenablage irgendwann mal am laufen habe, tue ich das.
Habe die Gasterweiterungen schon installiert und neu gestartet.
Funktioniert trotzdem nicht.

[BananaJoe]

@aleks-83 du kannst doch auch mit puTTY oder dem Terminalprogramm deiner Wahl in die VM gehen (per SSH)

[aleks-83]

@bananajoe

free -ht --mega

optiplex@Debian:~$ free -ht --mega
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:        10G        747M        9,4G        593K        319M        9,4G
Swap:           1,0G          0B        1,0G
Gesamt:          11G        747M         10G