Ram läuft voll
-
@homoran said in Ram läuft voll:
hast du die Skripte identifiziert und an der genannten Stelle den Ack-flag korrigiert?
Genau, ich habe geschaut welches Script dort auftaucht und an was er Meckert, meistens an ack-flag, manchmal an (null) in den DP's
@homoran said in Ram läuft voll:
Das war ja auch nicht die Ursache (falls du vom Einfrieren redest)
Dachte wenn er im Sekundentakt etwas in die Log schreibt, weil er mit einem DP nichts anfangen kann das es da irgendwie bei dem Versuch den Ram zu müllt ?
Genau, erst sterben einige Adapter ab, irgendwann ist ioB ganz weg. In der Konsole hab ich dann mal gesehen, das er dabei alle Adapter abschaltet.
Wie kann ich das dann verstehen, das er den Ram dann so schnell füllt, wenn es ein Script ist.
-
@d3ltoroxp sagte in Ram läuft voll:
an was er Meckert, meistens an ack-flag
und dabei steht dann das entsprechende Skript ( oft incl. der Position des Fehlers mit Angabe von Zeile und Position)
etwa so:
2021-05-01 03:43:02.589 - warn: backitup.0 (3131) Read-only state "backitup.0.output.line" has been written without ack-flag with value "[EXIT] 0"@d3ltoroxp sagte in Ram läuft voll:
weil er mit einem DP nichts anfangen kann
er kann - es ist nur ein WARN!
@d3ltoroxp sagte in Ram läuft voll:
In der Konsole hab ich dann mal gesehen
und wo ist diese Info in Form eines Auszugs in code-tags??
-
@d3ltoroxp sagte in Ram läuft voll:
Ich habe 3 VM's und 2 LXC's insgesamt habe ich bei den anderen 6GB vergeben bei ioB 8GB, dann komme ich auf 14 GB, also sollte ich ja im Rahmen des gesamten sein.
nein, weil deinem Host selbst ja auch noch Ram zugeteilt ist, somit hast du mehr vergeben als Verfügbar
-
@homoran said in Ram läuft voll:
und wo ist diese Info in Form eines Auszugs in code-tags??
Das war nicht heute, leider auch nur in der Konsole in Proxmox, ich hatte das da nur zufällig gesehen.
@crunchip said in Ram läuft voll:
nein, weil deinem Host selbst ja auch noch Ram zugeteilt ist, somit hast du mehr vergeben als Verfügbar
Stimmt, den gibt es ja auch noch. Was ist denn das dann für ne Anzeige auf der Proxmox Hauptseite, 6.05 GiB von 15.52 GiB ist das nicht alles zusammen, inkl. Host selber ? Mein Stand war, so lange der gesamte Ram nicht wirklich überschritten wird, macht das nichts, egal was man wem vergeben hat ?
-
@homoran sagte in Ram läuft voll:
which nodejs node npm && nodejs -v && node -v && npm -v && sudo apt update && sudo apt update && apt policy nodejs
Jetzt muss ich doch einmal nachfragen: Wieso verwendet hier jeder diese Zeile, in der zweimal
sudo apt updateausgeführt wird?
Muss update tatsächlich zweimal abgefragt werden? Und wenn ja, warum? -
@d3ltoroxp sagte in Ram läuft voll:
Was ist denn das dann für ne Anzeige auf der Proxmox Hauptseite, 6.05 GiB von 15.52 GiB
das rund 6Gb von deinen 16GB in Gebrauch sind, hat aber nichts damit zu tun, das du addiert mehr vergeben hast als tatsächlich zur Verfügung steht.
vereinfachtes Beispiel
Gesamt 16GB
Host 4GB, benutzt 3GB
VM1 6GB, benutzt 3GB
VM2 8GB, benutzt 5GB
VM3 4GB, benutzt 3GB
sind addiert
vergeben 22GB, in Gebrauch 14GB(theoretisch noch 2GB Luft)sollte nun die ein oder andere Maschine deutlich mehr Ram brauchen, kann es passieren, das die 16GB erreicht werden und der Host abschmiert.
Heisst, nicht die Zahlen addiert was aktuell verbraucht wird, ist entscheidend, sondern die Gesamtvergabe sollte/darf nicht größer sein als generell zu Verfügung steht, damit es zu keiner Überschreitung kommen kann.
-
@crunchip
Klasse anschaulich erklärt. Darüber bin ich ganz am Anfang auch mal gestolpert.Ich habe bei mir 2 GB für den Host frei gelassen, aber mal so aus Interesse: Wo kann ich eigentlich den zugeteilten Speicher für den Host sehen oder einstellen? Ich finde da nichts.
Mir fällt gerade ein:
So komische Effekte tauchen auch auf wenn die Festplatten überbelegt sind. -
@chaot sagte in Ram läuft voll:
Wo kann ich eigentlich den zugeteilten Speicher für den Host sehen oder einstellen?
Ja, das würde mich auch interessieren.
Ich starte jede Nacht meine VM iob neu damit diese nicht voll läuft.
Habe also somit das gleiche Problem.Und noch ne Zusatzfrage:
@crunchip
Zählt man bei deiner Addition nur die aktiven VM dazu? -
@chaot sagte in Ram läuft voll:
Ich habe bei mir 2 GB für den Host frei gelassen, aber mal so aus Interesse: Wo kann ich eigentlich den zugeteilten Speicher für den Host sehen oder einstellen? Ich finde da nichts.
gute Frage, bei der Installation wird nur die Swap Größe festgelegt (siehe rechts in der Proxmox Gui), ausser man verwendet ZFS , dann gibt es keinen Swap.
Sollte man ZFS verwenden, muss/sollte dies konfiguriert werden (ZFS ARC Tuning), wieviel Ram ZFS benutzen darf.
Ansonsten bin ich da auch nur Laie und nicht all zu großen Plan von der ganzen Materie -
@chaot dem Host teilt man keinen Speicher zu, es ist der Host, der verteilt den Speicher an sich selbst und an die VMs
Und Überbelegung von Festplattenplatz ... ganz böse Sache aus meiner Sicht. Wenn man das macht braucht es unbedingt ein Monitoring das rechtzeitig alarmiert wenn der Crash droht.Ich habe beruflich viel damit zu tun:
- Wenn auf dem Virtualiserungshost die Festplatte vollläuft ist schnell "Ende Gelände", im schlimmsten Fall ist die VM schwer beschädigt / die Daten verloren. In neuen Versionen greifen die Host manchmal noch rechtzeitg ein und frieren die VMs ein.
- Die VM weis davon ja nichts. Die sieht nur "Hurra, noch 5GiB frei"
- gleiches gilt für den RAM. Oh, Cool, 6GiB RAM, da richtige ich mir doch einen größeren Cache ein. Bei Überbelegung versucht der Virtualisierungshost (Hypervisior) zu retten was zu retten ist, z.B. durch Balloning. Dabei wird über einen Treiber im System viel Arbeitsspeicher angefordert der an den Host zurück geht. Die VM lagert dann auf Festplatte aus. Du kannst dir aber merken: Wenn er das machen muss wird es ersteinmal ganz übel langsam, egal ob du SSD's oder NVMe hast. Nach einiger Laufzeit kann sich das beruhigen.
Also, Überprovisionieren von RAM und HDD ist böse, nach Möglichkeit nicht machen!
Bei mir läuft so eine Ubuntu-VM auch mit 512MiB ausreichen (ok, nicht die ioBroker VM), 1GiB reicht dann aber wirklich für das meiste (Webserver, Seafile usw.). Meine Windows-Server laufen auch mit 1 bis 2GiB. Ok, Windows Updates dauern dann sehr viel länger ...
Aber wenn das Betriebssystem weis das es wenig hat geht es auch gleich ganz anders damit um. -
@bahnuhr sagte in Ram läuft voll:
Zählt man bei deiner Addition nur die aktiven VM dazu?
na eigentlich alle angelegten, sonst müsste ich ja jedesmal erst durchrechen, ob ich die oder jene Maschine laufen lassen kann, ohne das es zu Problemen kommen kann.
@bahnuhr sagte in Ram läuft voll:
Ich starte jede Nacht meine VM iob neu damit diese nicht voll läuft
das ist eigentlich nicht nötig, das regelt das System von alleine (sollte zumindest)
-
Guten Morgen,
ich habe den iob in einer VM und dort 6GB Ram zugewiesen.
Und auch dieses "Balloning" ist an.
Sollte man dies ausschalten ? -
@bahnuhr jepp. Dann versucht er bei der VM nicht den Speicher zurück zu holen
-
@bananajoe sagte in Ram läuft voll:
@bahnuhr jepp. Dann versucht er bei der VM nicht den Speicher zurück zu holen
So, ich habs jetzt einmal bei der VM iob ausgeschaltet.
In der Übersicht steht es jetzt so:
Ist dies standardmäßig eingeschaltet ?
Bei den anderen ist der Haken noch drin.
Überall raus ? -
@bahnuhr öhm ich hab nur meinen Senf dazu gegeben weil es um Virtualisierung gibt, deine "was auch immer Lösung die ich oben im Text nicht finde" kenne ich nicht. Ich kann nur VMware ...
-
Ok, auf der Proxmox Seite steht:
Scheint wohl standard zu sein.
Habe den Haken wieder rein gemacht.mfg
-
@bahnuhr sagte in Ram läuft voll:
Ist dies standardmäßig eingeschaltet ?
ja,
ansonsten ist eine kleine Beschreibung, wenn du unterhalb von Ballooning auf die Hilfe klickst -
Hm ich hab jetzt probiert und probiert. Es gab immer wieder Fehler mit einem Script was auf DP's vom Calendar Adapter zugreift. Ich konnte es immer nicht verstehen warum. Er sagt die DP's sind nicht da, schaue ich rein sind sie vorhanden. Mir ist jetzt aufgefallen, das der Adapter die irgendwie löscht und wieder neu erstellt, dann wieder löscht und wieder erstellt. Jetzt nur 3 anstatt 28 Order vorhanden. Dann blieb er so stehen, aber die Log kam auch immer wieder das das Script die DP's nicht finden kann. Ich vermute der löscht und erstellt, löscht und erstellt, permanent die DP's. Der Ram füllt sich langsam. Auch im Objektbaum hat es ewig gedauert bis ich bei anderen DP's einen Wert hatte, sonst war immer (null) eine ganze weile drin. Jetzt hab ich den Adapter deaktiviert und der Ram liegt jetzt wieder bei 2,6 GB und bleibt Stand jetzt stabil. Auch im Objektbaum bekomme ich die Werte direkt angezeigt, nachdem ich einen Stamm öffne. Ich lass das jetzt mal so und beobachte.
-
@d3ltoroxp sagte in Ram läuft voll:
Es gab immer wieder Fehler mit einem Script was auf DP's vom Calendar Adapter zugreift. Ich konnte es immer nicht verstehen warum. Er sagt die DP's sind nicht da, schaue ich rein sind sie vorhanden
und warum zeigst du weder die Meldung noch die Objects?
Vielleicht sehen oder verstehen ja 30.000 mehr als einer.@d3ltoroxp sagte in Ram läuft voll:
Ich vermute
das wird dir nicht helfen. Wissen ist angesagt.
@d3ltoroxp sagte in Ram läuft voll:
Jetzt hab ich den Adapter deaktiviert und der Ram liegt jetzt wieder bei 2,6 GB und bleibt Stand jetzt stabil.
Also ist da immer noch ein böses Skript.
Warum gehst du nicht systematisch vor?
z.B. nach dem 50/50 Test? -
@homoran said in Ram läuft voll:
und warum zeigst du weder die Meldung noch die Objects?
Vielleicht sehen oder verstehen ja 30.000 mehr als einer.You are assigning a number to the state "0_userdata.0.Abfall.Restmüll_Days_left" which expects a string. Please fix your code to use a string or change the state type to number. This warning might become an error in future versions.ist aktuell behoben, habe von Zeichenkette auf Zahl umgestellt. Ist mir nun nicht mehr aufgefallen.
javascript.0 2022-01-02 09:31:05.853 info State value to set for "0_userdata.0.Abfall.Restmüll_Days_left" has to be type "string" but received type "number" javascript.0 2022-01-02 09:31:05.812 warn at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.812 warn at Immediate._onImmediate (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.812 warn at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.812 warn at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.812 warn at Object.<anonymous> (script.js.VIS.Abfallkalender:38:5) javascript.0 2022-01-02 09:31:05.811 warn at setState (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1437:20) javascript.0 2022-01-02 09:31:05.811 warn You are assigning a number to the state "0_userdata.0.Abfall.Restmüll_Days_left" which expects a string. Please fix your code to use a string or change the state type to number. This warning might become an error in future versions. javascript.0 2022-01-02 09:31:05.809 error at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.809 error at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.809 error at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.809 error at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.809 error at Object.<anonymous> (script.js.VIS.Abfallkalender:3:74) javascript.0 2022-01-02 09:31:05.809 error script.js.VIS.Abfallkalender: TypeError: Cannot read property 'indexOf' of null javascript.0 2022-01-02 09:31:05.808 warn at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.808 warn at Immediate._onImmediate (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.808 warn at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.808 warn at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.807 warn at Object.<anonymous> (script.js.VIS.Abfallkalender:3:8) javascript.0 2022-01-02 09:31:05.807 warn getState "calendar.0.YWtmZHQyMHUwZ3MxMzhxMTE4OW5xdn.4.events" not found (3) javascript.0 2022-01-02 09:31:05.805 error at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.805 error at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.805 error at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.805 error at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.805 error at Object.<anonymous> (script.js.VIS.Abfallkalender:3:74) javascript.0 2022-01-02 09:31:05.805 error script.js.VIS.Abfallkalender: TypeError: Cannot read property 'indexOf' of null javascript.0 2022-01-02 09:31:05.804 warn at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.804 warn at Immediate._onImmediate (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.804 warn at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.804 warn at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.803 warn at Object.<anonymous> (script.js.VIS.Abfallkalender:3:8) javascript.0 2022-01-02 09:31:05.803 warn getState "calendar.0.YWtmZHQyMHUwZ3MxMzhxMTE4OW5xdn.4.events" not found (3) javascript.0 2022-01-02 09:31:05.796 error at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.796 error at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.796 error at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.796 error at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.796 error at Object.<anonymous> (script.js.VIS.Abfallkalender:3:74) javascript.0 2022-01-02 09:31:05.796 error script.js.VIS.Abfallkalender: TypeError: Cannot read property 'indexOf' of null javascript.0 2022-01-02 09:31:05.794 warn at processImmediate (internal/timers.js:464:21) javascript.0 2022-01-02 09:31:05.794 warn at Immediate._onImmediate (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 2022-01-02 09:31:05.794 warn at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 2022-01-02 09:31:05.794 warn at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 2022-01-02 09:31:05.794 warn at Object.<anonymous> (script.js.VIS.Abfallkalender:3:8) javascript.0 2022-01-02 09:31:05.788 warn getState "calendar.0.YWtmZHQyMHUwZ3MxMzhxMTE4OW5xdn.4.events" not found (3)
Das ist mal voll mit 28 Ordnern, jetzt wieder leer und so bleibt es auch. Wenn man in dem Baum bleibt und beobachtet, kann man sehen, wie die Ordner erstellt werden und dann auch wieder verschwinden.
Das Script was auf die DP's zugreifen will meckert dann natürlich wenn die DP's nicht vorhanden sind.
@homoran said in Ram läuft voll:
Also ist da immer noch ein böses Skript.
Scripte laufen jetzt alle, bis auf das was auf die fehlenden DP's zugreifen will, da die immer wieder gelöscht werden und auch nicht mehr dazu kommen, die Fehler vom Script, also sollte es stimmen.
Auch unter Objekte flutscht jetzt alles, beim öffnen beim anzeigen der Werte in den DP's. Alles seitdem der Calendar Adapter aus ist.
