Steigender RAM Verbrauch normal?

[Thomas Braun]

@homoran sagte in Steigender RAM Verbrauch normal?:

ziemlich weit unten scheint noch etwas mit unglaublichen 635MB zu stehen.
sae oder so.

Das dürfte von dem deCONZ kommen. Der läuft soweit ich weiß mit Java.

[Homoran]

@thomas-braun braucht ja schon fast den ganzen sonst freien RAM.
ist soviel normal?

und warum steht das nicht ganz oben wenn nach MEM sortiert ist?

gibt es noch weiter unten ggf. noch mehr Überraschungen?

Fragen über Fragen

[Thomas Braun]

@homoran sagte in Steigender RAM Verbrauch normal?:

und warum steht das nicht ganz oben wenn nach MEM sortiert ist?

Ist es ja nicht. Es ist nach RES sortiert.
Da sind libraries usw. mit gezählt.

Es müsste nach MEM% geschaut werden.

[zeron850]

@thomas-braun
@Homoran

Guten Abend Zusammen,
ich habe jetzt die Daten wie gewünscht eingefügt. Sorry hatte die Anforderungen nicht ganz verstanden.

top - 18:42:10 up 1 day, 8 min,  1 user,  load average: 1,31, 1,59, 1,63
Tasks: 161 total,   2 running, 159 sleeping,   0 stopped,   0 zombie
%CPU(s): 18,6 us,  4,2 sy,  0,0 ni, 76,0 id,  0,1 wa,  0,0 hi,  1,2 si,  0,0 st
MiB Spch:   3712,1 total,    630,4 free,   2805,7 used,    276,0 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.    650,0 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   2184 sae       20   0 4477396 713016  20060 S   5,0  18,8  56:05.65 java
   2370 iobroker  20   0 1184524 319952  28228 R  40,4   8,4 708:11.37 iobroker.js-con
   3151 iobroker  20   0 1048808 180592  28908 S  11,6   4,8 199:13.79 io.javascript.0
   2885 iobroker  20   0 1028280 151780  28152 S   0,0   4,0   3:38.47 io.admin.0
   4226 iobroker  20   0 1001424 142588  24064 S   3,3   3,8  53:21.49 io.zwave2.0
   3876 iobroker  20   0  746740 131020  22096 S   0,7   3,4  12:37.22 io.sonoff.0
   4057 iobroker  20   0  683272 105492  22608 S  18,2   2,8 284:22.59 io.sma-em.0
   4128 iobroker  20   0  950052  95472  22784 S   0,0   2,5  12:19.52 io.web.0
   3908 iobroker  20   0  696140  92796  22116 S   0,3   2,4  32:17.75 io.mqtt.0
   3968 iobroker  20   0  880588  85072  26736 S   0,7   2,2   2:38.32 io.backitup.0
   4297 iobroker  20   0  923868  84568  24196 S   1,0   2,2  15:52.60 io.fb-checkpres
   4143 iobroker  20   0  683536  82432  22440 S   0,0   2,2   5:06.59 io.yahka.0
   3730 iobroker  20   0  943016  79468  22592 S   0,0   2,1  26:12.73 io.tahoma.0
   5059 iobroker  20   0  939264  78264  23536 S   0,0   2,1   6:59.40 io.tr-064.0
   4005 iobroker  20   0  673732  76340  23200 S   0,0   2,0   4:51.78 io.deconz.0
   3235 iobroker  20   0  695288  73796  23216 S   0,0   1,9   3:08.45 io.sql.0
   4436 iobroker  20   0  692804  70344  23736 S   5,6   1,9   6:40.32 io.simple-api.0
   4425 iobroker  20   0  937424  70116  24516 S   0,0   1,8   2:32.00 io.bluelink.0
   3606 iobroker  20   0  657580  67468  21864 S   1,0   1,8  11:37.10 io.modbus.0
   3979 iobroker  20   0  934536  66444  24548 S   0,0   1,7   3:00.99 io.bmw.0
   3620 iobroker  20   0  653820  65876  22676 S   0,0   1,7   6:31.65 io.rpi2.0
   3323 iobroker  20   0  931232  65024  22224 S   0,0   1,7   2:16.37 io.pushover.0
   4250 iobroker  20   0  667048  63760  22332 S   0,3   1,7   2:26.54 io.trashschedul
   4408 iobroker  20   0  651280  63136  26800 S   0,0   1,7   3:35.75 io.logparser.0
   4208 iobroker  20   0  651924  62744  22864 S   0,3   1,7   4:31.47 io.fullybrowser
   3401 iobroker  20   0  798268  62620  22916 S   0,0   1,6   2:32.75 io.pushover.1
   3616 iobroker  20   0  657204  62548  21884 S   1,0   1,6  10:10.24 io.modbus.1
   4155 iobroker  20   0  649048  59764  21808 S   0,3   1,6   2:29.92 io.discovery.0
   4355 iobroker  20   0  666592  57208  21900 S   0,0   1,5   2:14.72 io.signal-cmb.0
   2146 dietpi    20   0  407172  39828  24252 S   1,0   1,0  20:10.86 deCONZ
   2033 root      20   0   21016   7300   6404 S   0,0   0,2   0:05.39 systemd-journal
      1 root      20   0  165300   7160   4856 S   0,0   0,2   0:06.46 systemd
 372879 root      20   0   10844   5752   3088 S   0,0   0,2   0:00.10 bash
   2497 mosquit+  20   0   14084   4436   3416 S   0,3   0,1   2:28.57 mosquitto
   2262 root      20   0   99336   3976   2676 S   0,0   0,1   0:00.01 dhclient
   2365 root      20   0   14928   3916      0 S   0,0   0,1   0:01.31 dietpi-dashboar
 372906 root      20   0   11800   3220   2680 R   0,7   0,1   0:09.13 top
 372841 root      20   0    4556   2768   2424 S   0,3   0,1   0:01.06 dropbear
   2139 root      20   0    8652   2400   1980 S   0,3   0,1   2:01.82 deCONZ-update2.
   2179 root      20   0   13088   2380   1876 S   0,0   0,1   0:00.01 sudo
   2053 root      20   0   19744   2284   1200 S   0,0   0,1   0:01.21 systemd-udevd
   2482 dietpi    20   0   19220   2276   1040 S   0,0   0,1   0:07.88 proftpd
   2134 _rpc      20   0    8088   2104   1672 S   0,0   0,1   0:00.28 rpcbind

Zudem habe ich heute Abend den RAM Verbrauch nochmal überprüft. Seit dem Update auf Node JS 16.17 benötigt er sogar mehr Speicher als vorher. Gestern hatte ich um die Zeit rund 2,5G verbraucht und heute sind es sogar fast 3,0G....

Gestern und Heute

sae ist der SmartApplianceEnabler eine Software zur Einbindung von Photovoltaikkomponenten in eine Cloud der Fa. SMA von einem freien Programmierer. Diese läuft seit ich den C4 habe darauf und verbraucht zwischen 630 und 730 MB konstant. Ein Wachstum des Verbrauches gibt es hier nicht...

[Thomas Braun]

@zeron850

Warum hast du eigentlich das swap ausgeschaltet?
Sonst noch 'Tuningmaßnahmen' in der Richtung unternommen?

[zeron850]

@thomas-braun

Das swap ist standardmäßig bei DietPi deaktiviert. Natürlich könnte ich das einschalten, aber dann habe ich statt freezing einfach ein langsames System das hakt. Nein keine weiteren Tuning Maßnahmen, da ich DietPi in der Basiskonfiguration nutze.

[Thomas Braun]

@zeron850

Bis auf den dicken Java-Brocken sehe ich da eigentlich nix wildes.

[zeron850]

@thomas-braun

So geht es mir selbst ja auch und deshalb war ich ratlos was ich noch unternehmen könnte um das Speicherproblem in den Griff zu bekommen.

[Thomas Braun]

@zeron850 sagte in Steigender RAM Verbrauch normal?:

Speicherproblem

Ich sehe nichtmal das.

[zeron850]

@thomas-braun

Wie meinst das? Freezing ist doch kein normaler Zustand?

[Homoran]

@thomas-braun sagte in Steigender RAM Verbrauch normal?:

@zeron850 sagte in Steigender RAM Verbrauch normal?:

Speicherproblem

Ich sehe nichtmal das.

sehe ich auch so.
bis jetzt haben wir keine Situation gezeigt bekommen, bei der available RAM=0 ist

[Lucky_ESA]

Hallo zusammen,

muss mich auch mal zu Wort melden. Habe ein Pi4 mit 4GB Ram und die 64Bit Lite installiert.
Mittlerweile startet bei mir der iobroker 2 x täglich neu.

Habe mir dann ein Script geschrieben was mir den RAM verbrauch aufzeigt und speichert.
Sehr auffällig ist hier der ical der dann den restlichen RAM für sich beansprucht und dann kommt es zum Neustart.

Von 100MB auf ca. 400MB und dann auch über 600MB.

Schau den Verbrauch bei dir mal an. Kann dir auch gerne mein Blockly zur Verfügung stellen allerdings weiß ich nicht wie ich die Ansicht aus IQOntrol bekomme.

Alle RAM

Es werden auch alle Termin auf dem Laufwerk abgelegt welche auch laut Code eingelsen werden.

Cache vom ical

Hier der Ram Verbrauch der zum Absturz führt

Werde es mal weiter beobachten.

Gruß//Lucky

[zeron850]

@homoran
@Thomas-Braun

Stelle ich dann morgen ein wenn es wieder soweit ist...

[Homoran]

@zeron850 sagte in Steigender RAM Verbrauch normal?:

heute sind es sogar fast 3,0G....

bilde ich es mir ein, oder flacht da die Kurve gerade ab?

[Thomas Braun]

@lucky_esa

Wo siehst du denn in den Prozessen des TE den ical?

[zeron850]

@homoran

Leider nein das denke ich auch jedes Mal und dann steigt er weiter. Aktuell ist er bei 3,2G
Heute Nacht ist dann Ende...

[Thomas Braun]

@zeron850

Und wie ist die MEM%-Verteilung?
Kann man mit htop imho besser sehen.
Ich vermute da ja immer noch den Java-Brocken.

Gerade mal in mein Sytem geschaut:

[apollon77]

@lucky_esa iCal? Wie groß sind denn so die Kalender dienstags verarbeitet werden? Vllt mal die Vergangenheit aufräumen? Bedenke das er am Ende das ganze Kalenderfile im RAM haben muss und es dann Eintrag für Eintrag verarbeitet.

Auch hier wäre ein log mal sinnvoll. Auch was da genau neu startet. Vor allem: iobroker 2.0? Und das ist dann mit nodejs 14 oder 16 oder was?

[Homoran]

@zeron850
was mich sehr wundert ist dass bei dir free und available so dicht beieinander liegen.

ist das DietPi spezifisch?

[zeron850]

@thomas-braun
@Homoran

Anbei mal mit htop. Wie sortiere ich da nach MEM%?

Bei einem anderen Server den ich als NAS nutze liegen die beiden Werte auch sehr dicht beinander.