NEWS
NUC-Proxmox-steigender Ram
-
@crunchip
Gerade gesehen, dass der Admin ja auf "Debug" steht. Darum sehe ich diese Einträge bei mir nicht.
Dann brauche ich mich ja nicht zu wundern. Alles gut.Bleibt trotzdem ein Mysterium.
Kann mir kaum vorstellen, dass es an ioBroker liegt. Das würde hier sonst dutzendfach aufschlagen.
Irgendetwas ist an der Installation von Proxmox anders als bei allen anderen.
Wobei ich zugeben muss, dass ich meines auch nicht stringent nach irgend einer Anleitung installiert habe. Bootfähigen Stick erzeugt und dann gestartet. Der Rest ist eigentlich selbsterklärend.@codierknecht sagte in NUC-Proxmox-steigender Ram:
Gerade gesehen, dass der Admin ja auf "Debug" steht. Darum sehe ich diese Einträge bei mir nicht
korrekt
und extra chatgpt bemüht(zu faul zum suchen):grin:Die Umstellung von der internen ioBroker-Datenbank auf Redis erfolgte mit der Einführung der Version 1.5.0 des ioBroker.js-Controllers, die am 16. September 2018 veröffentlicht wurde@codierknecht sagte in NUC-Proxmox-steigender Ram:
rgendetwas ist an der Installation von Proxmox anders als bei allen anderen
keine Ahnung, daher fragte ich ja nach dem syslog
-
@codierknecht sagte in NUC-Proxmox-steigender Ram:
Gerade gesehen, dass der Admin ja auf "Debug" steht. Darum sehe ich diese Einträge bei mir nicht
korrekt
und extra chatgpt bemüht(zu faul zum suchen):grin:Die Umstellung von der internen ioBroker-Datenbank auf Redis erfolgte mit der Einführung der Version 1.5.0 des ioBroker.js-Controllers, die am 16. September 2018 veröffentlicht wurde@codierknecht sagte in NUC-Proxmox-steigender Ram:
rgendetwas ist an der Installation von Proxmox anders als bei allen anderen
keine Ahnung, daher fragte ich ja nach dem syslog
@crunchip
okay, auf debug wird es aufgeführt.2024-09-26 06:42:42.326 - info: host.ioTest stopInstance system.adapter.admin.0 (force=false, process=true) 2024-09-26 06:42:42.330 - info: admin.0 (4493) Got terminate signal TERMINATE_YOURSELF 2024-09-26 06:42:42.331 - info: admin.0 (4493) terminating https server on port 8081 2024-09-26 06:42:42.332 - info: admin.0 (4493) terminating 2024-09-26 06:42:42.332 - info: admin.0 (4493) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2024-09-26 06:42:42.371 - info: host.ioTest stopInstance system.adapter.admin.0 send kill signal 2024-09-26 06:42:42.833 - info: admin.0 (4493) terminating 2024-09-26 06:42:42.859 - info: host.ioTest instance system.adapter.admin.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2024-09-26 06:42:45.965 - info: host.ioTest instance system.adapter.admin.0 in version "7.1.2" started with pid 5251 2024-09-26 06:42:46.371 - debug: admin.0 (5251) Redis Objects: Use Redis connection: 127.0.0.1:9001 2024-09-26 06:42:46.378 - debug: admin.0 (5251) Objects client ready ... initialize now 2024-09-26 06:42:46.379 - debug: admin.0 (5251) Objects create System PubSub Client 2024-09-26 06:42:46.379 - debug: admin.0 (5251) Objects create User PubSub Client 2024-09-26 06:42:46.383 - debug: admin.0 (5251) Objects client initialize lua scripts 2024-09-26 06:42:46.385 - debug: admin.0 (5251) Objects connected to redis: 127.0.0.1:9001 2024-09-26 06:42:46.389 - debug: admin.0 (5251) Redis States: Use Redis connection: 127.0.0.1:9000 2024-09-26 06:42:46.390 - debug: admin.0 (5251) States create System PubSub Client 2024-09-26 06:42:46.390 - debug: admin.0 (5251) States create User PubSub Client 2024-09-26 06:42:46.392 - debug: admin.0 (5251) States connected to redis: 127.0.0.1:9000 2024-09-26 06:42:46.398 - debug: admin.0 (5251) Plugin sentry Initialize Plugin (enabled=true) 2024-09-26 06:42:46.462 - info: admin.0 (5251) starting. Version 7.1.2 in /opt/iobroker/node_modules/iobroker.admin, node: v20.17.0, js-controller: 6.0.11 2024-09-26 06:42:46.472 - info: admin.0 (5251) requesting all objectspeter@ioTest:~$ iob status iobroker is running on this host. Objects type: jsonl States type: jsonl peter@ioTest:~$ -
DIE bebilderte Anleitung habe ich nicht gefunden.
Unter Proxmox nutze ich VMs.
Einen CT habe ich jetzt mal für diesen Test hier erstellt.
Dazu erstmal im Proxmox Host die aktuelle Debian 12 Vorlage heruntergeladen.
Dann auf erstelle CT klicken, das Template auswählen, 20GB Disk, 4 CPU Kerne in einem Sockel, 8 GB RAM, bei Netzwerk evtl. noch das VLAN setzen, DHCP an, starten.
Dann als root sudo installieren.
apt update apt install sudo apt install curl adduser benutzername usermod benutzername -aG sudo exitDann als benutzername einloggen
sudo apt update sudo apt install qemu-guest-agent curl -sLf https://iobroker.net/install.sh | bash -Das ist das Grundsystem, welches bei mir seit gestern testet.
Unter Objekte werden noch System freies RAM, RAM-Prozent und der Speicher vom admin in die History geloggt.
@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
-
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
@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-
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. -
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?
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
-
@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-
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. -
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?
@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
-
-
@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 ...
-
@crunchip
Gerade gesehen, dass der Admin ja auf "Debug" steht. Darum sehe ich diese Einträge bei mir nicht.
Dann brauche ich mich ja nicht zu wundern. Alles gut.Bleibt trotzdem ein Mysterium.
Kann mir kaum vorstellen, dass es an ioBroker liegt. Das würde hier sonst dutzendfach aufschlagen.
Irgendetwas ist an der Installation von Proxmox anders als bei allen anderen.
Wobei ich zugeben muss, dass ich meines auch nicht stringent nach irgend einer Anleitung installiert habe. Bootfähigen Stick erzeugt und dann gestartet. Der Rest ist eigentlich selbsterklärend.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.
-
@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
-
@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-
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. -
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?
-
-
@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 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?
-
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)@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.
-
@marko67 dann gehen mir langsam die Ideen aus
-
@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.
topsagt 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 MemEdit: Nach über 3 Stunden 720 MB Auslastung - davon hat der Admin 145 MB.
-
@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.
topsagt 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 MemEdit: Nach über 3 Stunden 720 MB Auslastung - davon hat der Admin 145 MB.
@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...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@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...
@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.
-
@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.
@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 @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?
@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 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?
@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
Support us
763
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge