NUC-Proxmox-steigender Ram

[crunchip]

@peterfido sagte in NUC-Proxmox-steigender Ram:

DIE bebilderte Anleitung habe ich nicht gefunden.

diese Dreiecke sind aufklappbar

@marko67 sagte in NUC-Proxmox-steigender Ram:

Haben den Adapter gelöscht. 1x über ioB Adapter und dann mal über die Konsole. Meldung taucht immer wieder auf??

seltsam

kannst du testweise einen neuen LXC erstellen, diesmal aber ein ubuntu template nehmen und mal nur eine reine Installation, ohne irgend etwas einzurichten oder zu löschen, nach der iobroker Installation

[MartinP]

@marko67 sagte in NUC-Proxmox-steigender Ram:

Mein Problem ist, dass der RAM bis auf 100% hoch läuft und dann auch andere Container einfrieren. So war es auf dem vorherigen System.
Hier mal der RAM Verbrauch nach knapp 3 Stunden

1. Wenn man ein sicheres System haben will, darf man in Summe nur so viel RAM auf die Container verteilen, wie Proxmox bereitstellen kann ...
   Hast Du ein System mit 8 GB RAM und drei Containern, sollte man nicht mehr als ca 7,5 GB auf die drei Container verteilen, also z.B. 2,5 + 2,5 + 2,5
   Verteilt man mehr, als vorhanden ist auf die Container, gibt es die von Dir beobachteten Symptome, wenn einer der Container amok läuft, und ausnutzt, was ihm zusteht.

2. Meine Frage war, wie sich das RAM verhält, WÄHREND der iobroker durch "iob stop" gestoppt ist.
   Sinkt die "Memory usage" wieder?
   Auf den ursprünglichen Stand vor dem ersten Start des iob?

[crunchip]

@martinp laut seiner Aussage hat er doch 16GB Gesamt
8Gb für iobroker und 2weitere LXC mit 1 und 2 GB Ram, sollte in Summe dann ja passen

@martinp sagte in NUC-Proxmox-steigender Ram:

Sinkt die "Memory usage" wieder?

ja, hat er oben doch schon gezeigt

[MartinP]

@marko67 sagte in NUC-Proxmox-steigender Ram:

iob stop ausgeführt. Ist mit 157 MB neu gestartet und nun wieder bei fast 1,5 GB steigend

Sorry, hatte nur die grafische Auswertung beachtet, und da keinen Abfall der RAM-Nutzung durch IOB gesehen

Ist "Nesting" im Lxc-Container aktiviert?

Und hier die Netzwerk-Einstellungen des Containers:

Da habe ich gegenüber der Fritzbox getrickst ...

[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."