Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Jan1]

@Humidor sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

Hardwaresystem:
Pi3B +

Arbeitsspeicher:
1GB

ist eben nicht viel

[Humidor]

@Jan1 sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

@Humidor sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

Hardwaresystem:
Pi3B +

Arbeitsspeicher:
1GB

ist eben nicht viel

dh iobroker killt sich selbst an den Ressourcen?
Datenträger verfügbar: 83.4 %, gesamte RAM-Nutzung: 920 MB / Frei: 44% = 411 MB

[Jan1]

@Humidor
Es gibt viel Möglichkeiten warum der RAM ausgeht. Ich hatte auch den PI3B+ und eher weniger Probleme mit dem RAM, aber war immer schwer an der Grenze.
Viele Adapter und Instanzen, oder einfach ein Script, das ein Loop auslöst und das 1GB RAM reicht nicht mehr. Im Log wird es ja angezeigt, dass zu dem Zeitpunkt kein RAM mehr zur Verfügung stand. Da Du jetzt wieder genügend frei hast, tippe ich auf ein fehlerhaftes Script.

[Humidor]

@Jan1
letzte Script Änderung war diese:

[Humidor]

@Humidor
jetzt sagt er mir ich soll iQontrol updaten

[Jan1]

@Humidor
es kann auch bei einem Update der RAM ausgehen und je nach dem was Du gerade updatest, kann es dabei zu einem Abbruch kommen, wie geschrieben, es gibt sehr viele Möglichkeiten.

[Humidor]

@Jan1
OK, dann gehe ich von einem RAM Überlauf aus, da er viele Adapter hintereinander upgedatet hat. Das mach ich dann so nicht mehr. Danke!

[Jan1]

@Humidor
Wenn Du updatest, dann schalte vorher ein paar Adapter aus, das spart schon mal viel RAM und somit sollte ein Update auch nicht zu einem RAM Überlauf führen.
@Thomas-Braun wird dir dann noch was zum Runlevel sagen, was unter Umständen noch mal richtig spart ;-)

[Humidor]

@Jan1

Danke!

kann man zu dem ständigen pollen vom web. auf ein sinnlose?? IP Adresse was sagen oder abstellen? gibt es noch weitere Einträge die Optimierung haben möchten ?

[apollon77]

@Humidor Sorry aber das ist blödsinn. Wenn das RAM so "voll" ist das es bei einem Update eines normalen Adapters (ich nehme jetzt mal "sql" aus gewisen gründen aus) kritisch wird ist einfach generell zuviel am laufen.

Also die üblichen Fragen bei "uups RAM knapp" ist: Wieviele Instanzen laufen denn so bei dir?
Was sagt "top" wenn du nach RAM verbrauch schaust?

Bedenke bitte das jeder Adapter mindestens 30-50MB RAM benötigt, einige wenige auch mal mehr. Bedeutet das bei 50MB im Schnitt und 20 Instanten laut Adam Riess schon 1 GB voll ist - und da hat das Linux System selbst noch nichts gehabt. Daher liegt ein sinnvolles Limit bei 1GB (und ohne den Compact Mode zu nutzen) bei 10-12 Instanzen ...

[Humidor]

@apollon77 Datenträger verfügbar: 83.3 %, gesamte RAM-Nutzung: 865 MB / Frei: 42% = 390 MB [Host: humidor - 14 Prozesse]

[Homoran]

@Humidor sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

gesamte RAM-Nutzung: 865 MB / Frei: 42% = 390 MB

das passt aber bei 1GB RAM nicht

[Humidor]

@Homoran
standard raspi3b+, ich hab daran nix verändert

[Homoran]

@Homoran sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

@Humidor sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

gesamte RAM-Nutzung: 865 MB / Frei: 42% = 390 MB

das passt aber bei 1GB RAM nicht

bitte wie von @apollon77 gebeten, die ausgabe von top auf der Konsole

[Humidor]

@Homoran

[Homoran]

@Humidor bitte nicht das wichtigste oben abschneiden

[Humidor]

@Homoran sagte in Gestern Updates gemacht, heute nicht erreichbar ?:

@Humidor bitte nicht das wichtigste oben abschneiden

hab ich schon gesehen und geändert

[Homoran]

@Humidor ok - das erklärt die Werte in dem admin
102 free + 210 buffered = 301 avail.

Wenn du jetzt noch den output von iobroker list instances als text in code-tags zeigst, kann man noch besser sehen, wie dicht du an der Klippe stehst

[Humidor]

@Homoran

pi@humidor:~ $ iobroker list instances
+ system.adapter.admin.0                 : admin                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.backitup.0              : backitup              -  enabled
+ system.adapter.cloud.0                 : cloud                 -  enabled
  system.adapter.flot.0                  : flot                  -  enabled
+ system.adapter.fritzdect.0             : fritzdect             -  enabled
  system.adapter.harmony.0               : harmony               - disabled
+ system.adapter.history.0               : history               -  enabled
+ system.adapter.hs100.0                 : hs100                 -  enabled
  system.adapter.hue.0                   : hue                   - disabled, port: 443
+ system.adapter.info.0                  : info                  -  enabled
+ system.adapter.iot.0                   : iot                   -  enabled
+ system.adapter.javascript.0            : javascript            -  enabled
+ system.adapter.rpi2.0                  : rpi2                  -  enabled
+ system.adapter.telegram.0              : telegram              -  enabled, port: 8443, bind: 0.0.0.0
  system.adapter.vis-materialdesign.0    : vis-materialdesign    -  enabled
  system.adapter.vis.0                   : vis                   -  enabled
+ system.adapter.web.0                   : web                   -  enabled, port: 8082, bind: 192.168.0.153, run as: admin
+ system.adapter.zigbee.0                : zigbee                -  enabled, port: /dev/ttyACM0

+ instance is alive
pi@humidor:~ $ 

[Homoran]

@Humidor Beide Kenndaten sind grenzwertig.

13 Instanzen, dabei backitup, der definitiv während des Backups massiv RAM benötigt und javascript, bei dem der RAM Bedarf natürlich von Anzahl und Umfang der Skripte abhängt.

100MB free (selbst 300MB available) sind auch nur eine Momentaufnahme.
Wenn später Skripte starten, die mehr RAM benötigen, oder das backup kann es schon zu wenig sein.

Für sich gesehen sind beide Infoquellen "eigentlich" in Ordnung. Aber eben nur "eigentlich".