NUC-Proxmox-steigender Ram
-
mapped: 27491500K writeable/private: 5375652K shared: 0K
Das sind 5,3 TB
top hat er gar nicht gepostet ...
Sind aber alles [ anon ] Einträge, nicht nachvollziehbar, wer da zuschlägt ...
z. B hier 8,3 TB
000074a333e20000 8388480 ----- 0000000000000000 000:00000 [ anon ]
Bei mir
mapped: 22525484K writeable/private: 376652K shared: 0K
376 MB....
-
@martinp sagte in NUC-Proxmox-steigender Ram:
top hat er gar nicht gepostet ...
doch. vor 14 Stunden und darauf habe ich geantwortet. Kiste platt machen und neu beginnen.
Ro75.
-
@ro75 Das wäre auch mein Rat, wenn nicht der erste Post wäre...
Guten Abend
Ich habe auf einem NUC ein frisches aktuelles Proxmox installiert und in einem Container eine frische ioBroker Installation.Da gibt es dann zwei Möglichkeiten, wenn er noch einmal einen frischen LXC unter Proxmox aufbaut ...
Entweder es funktioniert, oder die Speicherprobleme kommen durch ein kaputtes Backup ins Haus ...
Mit den Backupdateien habe ich meine bisherige ioB Instanz aufgespielt.
Da aber einiges beim Ablauf sehr suboptimal lief (bullseye statt bookworm als Basis, root bei der Installation), wäre auch mein Rat inzwischen, von neuem mit einem frischen LXC-Container zu beginnen..
-
@martinp dazu hatte er doch geschrieben, dass dies ein neuer Lxc ist mit reiner iobroker Grundinstallation ohne das Backup installiert zu haben.
Daher war auch weiter oben meine Frage, seit wann Javascript mit in der Grundinstallation dabei ist( (hab schon ewig keinen neuen iobroker mehr aufgesetzt)
Ich würde test halber nochmal einen neuen Lxc erstellen, jedoch die Admin Version dann wechseln
@marko67 und bevor du wieder mit irgendwelchen Videos dein Glück probierst, lies die Doku dazu mal durch
-
@crunchip sagte in NUC-Proxmox-steigender Ram:
seit wann Javascript mit in der Grundinstallation dabei ist
hatte vor ca. 3 Wochen einen Test-PI neu mit Debian12 aufgesetzt. Da ist standardmäßig kein JS-Adapter installiert.
Ro75.
-
@ro75 dann passt aber seine Aussage nicht, siehe https://forum.iobroker.net/post/1201808
-
@marko67 sagte in NUC-Proxmox-steigender Ram:
Welche Alternative habe ich alle "alten" z.T. selbst erzeugten Datenpunkte wieder herzustellen, auf die alle meine JS-Skripte zugreifen?
Kann es sein das du deine object json ex/importiert hast, ähnlich wie hier?
https://forum.iobroker.net/post/1070475 -
Nein, habe ich nicht gemacht
-
Hallo
Ich habe alle Ratschläge von Euch befolgt und natürlich bin ich nicht mehr auf dem Stand vom 16.09.
@MartinP : Ich habe einen neuen Container aufgesetzt. Ohne Root mit aktuellem Debian12. Iobroker läuft ohne Backup „nackt“ nur mit Instanz „admin.0 und Backitup“.
Die Werte habe ich wie von Dir beschrieben abgelesen und hier gepostet (siehe Post von gestern). Der Container lief 2x voll dh 100% RAM und der Container konnte über Proxmox nicht mehr beendet werden.@crunchip @ro75 diese Aussagen sind vom 17.09. Ich hatte gestern 18.09. einen neuen sauberen Container aufgesetzt, um die Werte wie von @MartinP empfohlen zu ermitteln. Iobroker ohne Schnick und Schnack und nur Admin und Backitup.
@ro75 wenn man die ioB Erstinstallation macht, werden einem verschiedenen Adapter vorgeschlagen, die dann automatisch mit installiert werden. So war es in meinem Fall des JS-Adapters. Aber wie gesagt, ist Geschichte und nicht mehr relevant.@MartinP Ich habe mehrere Backup-Versionen getestet. Natürlich in verschiedenen Containern. Vom Juli und August. Mit allen Backup das gl. Verhalten.
-
@marko67 Leider bin ich mit meinem Latein am Ende, und habe keine Ideen mehr, was man machen könnte ...
-
@martinp wie schon mehrmals vorgeschlagen, die admin version zu ändern, entweder auf die latest wechseln oder aus dem stable ein downgrade und dann beobachten.
@marko67 sagte in NUC-Proxmox-steigender Ram:
wenn man die ioB Erstinstallation macht, werden einem verschiedenen Adapter vorgeschlagen, die dann automatisch mit installiert werden.
das würde ich mal sein lassen, da du durch dein späteres backup ja dann sowieso alles installierst
-
@crunchip sagte in NUC-Proxmox-steigender Ram:
@martinp wie schon mehrmals vorgeschlagen, die admin version zu ändern, entweder auf die latest wechseln oder aus dem stable ein downgrade und dann beobachten.
@marko67 sagte in NUC-Proxmox-steigender Ram:
wenn man die ioB Erstinstallation macht, werden einem verschiedenen Adapter vorgeschlagen, die dann automatisch mit installiert werden.
das würde ich mal sein lassen, da du durch dein späteres backup ja dann sowieso alles installierst
Wäre vielleicht eine Idee, im Installationsskript diesen Verwendungszweck der Installation abzufragen, und diesen Sermon dann zu überspringen, wenn es für das Einspielen eines Backups gedacht ist
-
So der Adapter Admin ist auf der Version 7.1.1 und der Container neu gestartet.
top - 17:02:18 up 0 min, 1 user, load average: 0.24, 0.14, 0.10 Tasks: 19 total, 1 running, 18 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.3 us, 1.4 sy, 0.0 ni, 94.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7096.0 total, 6649.1 free, 260.7 used, 186.3 buff/cache MiB Swap: 512.0 total, 512.0 free, 0.0 used. 6835.3 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 129 iobroker 20 0 21.1g 162956 43776 S 0.0 2.2 0:05.39 iobroker.js-con 307 iobroker 20 0 21.3g 129996 50688 S 1.7 1.8 0:04.51 io.admin.0 348 iobroker 20 0 21.0g 82216 49152 S 0.0 1.1 0:01.83 io.backitup.0 55 root 20 0 41440 14464 13696 S 0.0 0.2 0:00.08 systemd-journal 1 root 20 0 167760 11520 8704 S 0.0 0.2 0:00.32 systemd 135 root 20 0 15432 9216 7936 S 0.0 0.1 0:00.01 sshd 96 systemd+ 20 0 17892 8320 7296 S 0.0 0.1 0:00.09 systemd-network 111 root 20 0 16572 7552 6656 S 0.0 0.1 0:00.08 systemd-logind 297 postfix 20 0 43044 6912 6272 S 0.0 0.1 0:00.00 pickup 298 postfix 20 0 43088 6912 6272 S 0.0 0.1 0:00.00 qmgr 370 dirk 20 0 8572 4736 2816 R 0.0 0.1 0:00.01 top 108 message+ 20 0 9120 4608 4224 S 0.0 0.1 0:00.02 dbus-daemon 296 root 20 0 42660 4376 3840 S 0.0 0.1 0:00.00 master 367 dirk 20 0 5224 4352 2816 S 0.0 0.1 0:00.02 bash 133 root 20 0 6112 3948 3456 S 0.0 0.1 0:00.07 login 87 _rpc 20 0 7880 3840 3456 S 0.0 0.1 0:00.00 rpcbind 106 root 20 0 3600 2048 1920 S 0.0 0.0 0:00.00 cron 132 root 20 0 2516 1408 1408 S 0.0 0.0 0:00.00 agetty 134 root 20 0 2516 1408 1408 S 0.0 0.0 0:00.00 agetty -
Was du noch versuchen könntest, den Container mit IOB ausschalten und mal eine VM (anstatt Container) aufsetzen und beobachten ob das dann auch der Fall ist. Wenn es das gleiche Ergebnis ist, kannste ja einfach die Maschine wieder löschen.
Ansonsten mal einen RAM Test machen, nicht das der einen weg hat.
-
Ram Test kann ich machen.
Sind aber 2 neue 4GB Riegel. Das Problem hatte ich schon vorher mit 2x3GB Riegel
-
@marko67 Würde erstmal die Füße still halten, und warten, ob das RAM wieder ansteigt ...
-
@marko67 sagte in NUC-Proxmox-steigender Ram:
Sind aber 2 neue 4GB Riegel
Muss nichts heißen und was ist mit den anderen 8 GB?
-
@marko67 600mb Ram für 3 Prozesse ist meiner Meinung schon zu viel, zumindest zeigt das die Gui, wobei top nur rund 450 anzeigt.
Einfach mal beobachten, sobald es ansteigt ist etwas anderes faul. -
Ich werde morgen testen.
Es läuft noch eine VM mit 2GB Raspimatic ohne Auffälligkeiten. Alles wie auf meinem "alten" System
-
Steigt wieder
top - 19:07:04 up 2:05, 1 user, load average: 0.08, 0.09, 0.04 Tasks: 19 total, 1 running, 18 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.9 us, 1.2 sy, 0.0 ni, 92.7 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 7096.0 total, 5087.6 free, 1800.3 used, 208.2 buff/cache MiB Swap: 512.0 total, 512.0 free, 0.0 used. 5295.7 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 441 iobroker 20 0 22.7g 1.6g 51200 S 20.7 22.8 2:22.49 io.admin.0 129 iobroker 20 0 21.4g 203716 44416 S 0.0 2.8 0:31.70 iobroker.js-con 348 iobroker 20 0 21.0g 85976 49152 S 0.0 1.2 0:05.20 io.backitup.0 55 root 20 0 49636 15488 14720 S 0.0 0.2 0:00.13 systemd-journal 1 root 20 0 167760 11648 8832 S 0.0 0.2 0:00.40 systemd 135 root 20 0 15432 9216 7936 S 0.0 0.1 0:00.01 sshd 96 systemd+ 20 0 17892 8320 7296 S 0.0 0.1 0:00.10 systemd-network 111 root 20 0 16572 7552 6656 S 0.0 0.1 0:00.09 systemd-logind 566 postfix 20 0 43044 7040 6400 S 0.0 0.1 0:00.00 pickup 298 postfix 20 0 43088 6912 6272 S 0.0 0.1 0:00.00 qmgr 108 message+ 20 0 9120 4608 4224 S 0.0 0.1 0:00.03 dbus-daemon 567 dirk 20 0 8572 4608 2688 R 0.0 0.1 0:00.00 top 296 root 20 0 42660 4376 3840 S 0.0 0.1 0:00.02 master 367 dirk 20 0 5224 4352 2816 S 0.0 0.1 0:00.02 bash 133 root 20 0 6112 3948 3456 S 0.0 0.1 0:00.07 login 87 _rpc 20 0 7880 3840 3456 S 0.0 0.1 0:00.01 rpcbind 106 root 20 0 3600 2048 1920 S 0.0 0.0 0:00.01 cron 132 root 20 0 2516 1408 1408 S 0.0 0.0 0:00.00 agetty 134 root 20 0 2516 1408 1408 S 0.0 0.0 0:00.00 agetty
