UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[marko67]

@codierknecht

Genau so habe ich es gemacht. Da kann man ja eigentlich nichts falsch machen. Habe es mit der bebilderten Anleitung verglichen und 1:1 genau so gemacht.

[marko67]

@crunchip

Mach ich

Erledigt:

Nach über 2 Std.

[marko67]

@martinp

Das neue System (Hardware / neuer NUC) hat 16 GB Speicher.

der 1. Container iob hat 8GB der 2. iob-Test hat 4 GB

Sinkt die "Memory usage" wieder? --> Ja!! Ich gl. ich hatte davon einen Screenshot bereits gepostet.

[marko67]

@martinp

Ist "Nesting" im Lxc-Container aktiviert? --> Ja

[MartinP]

@marko67 und bei der statisch zugewiesenen 192.168.1.152 spuckt kein anderes Device in die Suppe? Lieg die Adresse im Range, den Dein Router per DHCP vergibt?

[marko67]

@martinp

Fritz.Box sagt nein. Kein anderes Gerät mit gleicher IP. Range geht bis 200.
Alle meine SH Geräte haben statische Nummern. --> Betreibe parallel seit 13 Jahren FHEM.
Bisher lief alles sehr gut parallel (seit ca. 8 Jahren)

[Chrunchy]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Fritz.Box sagt nein. Kein anderes Gerät mit gleicher IP. Range geht bis 200.
Alle meine SH Geräte haben statische Nummern.

Feste IPs sind kein Problem, allerdings sollte diese immer außerhalb der IP-Range des DHCP-Servers liegen. GGf. den Bereich des DHCP verkleiner.

[crunchip]

@marko67 dann gehen mir langsam die Ideen aus

[Dr. Bakterius]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Hat jemand von Euch in den letzten Tagen einen neuen LXC aufgesetzt mit aktueller Software und ioB?? Nur um mal den Gegentest zu machen.

Nun habe auch ich einen neuen LXC auf meinem Proxmox 8.2.6 aufgesetzt (Mini-PC mit einem n100 und 32 GB RAM). Und zwar mit dem aktuellen debian Template debian-12-standard_12.7-1_amd64.tar.zst.

Die weitere Vorgangsweise genau wie in der Anleitung durchgeführt. Nur den javascript-Adapter mit dem Assistenten installiert. Sonst nichts weiter installiert oder gelöscht.

Nach etwa einer Stunde bin ich stabil bei etwa 670 MB RAM-Belegung. top sagt noch:

top - 16:51:30 up 55 min,  1 user,  load average: 0.42, 0.47, 0.53
Tasks:  21 total,   1 running,  20 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.1 us,  2.4 sy,  0.0 ni, 88.2 id,  0.3 wa,  0.0 hi,  0.8 si,  0.0 st 
MiB Mem :   8192.0 total,   4706.1 free,    671.2 used,   2814.7 buff/cache     
MiB Swap:    512.0 total,    512.0 free,      0.0 used.   7520.8 avail Mem 

Edit: Nach über 3 Stunden 720 MB Auslastung - davon hat der Admin 145 MB.

[MartinP]

@dr-bakterius Im stable Repository wird aktuell admin 7.1.5 zum Aktualisieren angeboten ...

In den Releasenotes des Update Fensters aber keine Hinweise, dass ein Speicherleck gefixt wurde...

[Dr. Bakterius]

@martinp sagte in NUC-Proxmox-steigender Ram:

keine Hinweise, dass ein Speicherleck gefixt wurde

Vermutlich weil es keines gibt.

Ich habe auf meinem Produktivsystem gestern das Admin-Update installiert - keine Änderung feststellbar was den RAM-Bedarf angeht. Und auch bei der vorherigen Version keine Auffälligkeiten. Jetzt nach knapp 21 Stunden bin ich bei 765 MB. Also nur moderat gestiegen was völlig normal ist. Das ist offensichtlich ein Problem das nur @marko67 betrifft und mit ziemlicher Sicherheit nichts mit ioBroker zu tun hat.

[marko67]

@dr-bakterius @MartinP

Nach dem Hinweis auf die IP (spuckt ein anderes Gerät in die Suppe) habe ich festgestellt, dass ioB relativ viel Traffic produziert.
Da kam mir eine Einstellung im Admin Adapter in den Sinn. Nicht https und Passwort sondern "Prüfen ob aus dem Internet erreichbar"

Weiß jemand wofür das ist?

[Dr. Bakterius]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Weiß jemand wofür das ist?

Das ist eine Sicherheitseinstellung. Wenn das Feld nicht angehakt ist, wirst du eine Warnung erhalten wenn der ioBroker von außen erreichbar und somit angreifbar ist weil ein Port offen ist. Für Leute die wissen was sie tun, kann man diese Warnungen abdrehen.

Wenigstens verstehe ich das so. Und diese Einstellung hat sicher nichts mit deinem Problem zu tun. Hast du offene Ports?

[marko67]

@dr-bakterius

Ich habe einen offenen Port für mein OpenVPN auf einem 2. NUC (dieser soll von dem jetzigen abgelöst werden).

Folgendes habe ich festgestellt als ich den Hacken gesetzt habe:

Ohne Hacken... RAM steigt:

Mit Hacken ... RAM und Traffic fällt direkt

Das gleiche Verhalten konnte ich auf allen 3 Testcontainern reproduzieren. Test ioB24 (Container1) läuft seit 29 Stunden ruhig mit 300 MB

[Meister Mopper]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Ich habe einen offenen Port für mein OpenVPN auf einem 2. NUC (dieser soll von dem jetzigen abgelöst werden).

Dann probier doch mal https für den Adapter (da gibt es den Haken gar nicht), so läuft's bei mir, und es gibt über den Monat ein weitgehend konstantes Bild.

[marko67]

@meister-mopper

Hatte ich schon probiert. Auch damit hatte ich den Effekt, dass der RAM schlagartig und dauerhaft nach unten ging. Allerdings hatten mir andere Forenmitglieder mitgeteil, dass das nicht die Lösung ist und irgendwo ein anderes Problem in meinem System sein müsste

"Das in deinem System was nicht stimmen kann. Die wenigsten (inklusive mir) haben HTTPS und Auth aktiviert und da gibt es auch nicht diesen Effekt.

Ro75."

[Dr. Bakterius]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Ohne Hacken... RAM steigt:
Mit Hacken ... RAM und Traffic fällt direkt

Sehr seltsam. Ich hatte den Haken noch nie gesetzt und keine Probleme.

Da könnte sich die Überwachung der Erreichbarkeit von außen irgendwie aufschaukeln bzw. vielfach gestartet werden. Möglicherweise hängt das irgendwie mit deiner Netzwerk-Konstellation zusammen. Aber da sind dann die Profis gefragt ...