Proxmox/HAOS: RAM läuft langsam voll und HA reagiert im Frontend nicht mehr

Installation, HW & HA-OS
1

Hallo ihr Lieben!

Ich habe seit einigen Tagen ein Problem, welches ich leider nicht mehr gelöst bekomme. Seit einigen Tagen läuft langsam aber konstant der RAM meiner Proxmox VM voll. Leider Gottes hilft weder ein Reboot noch ein Backup-Einspielen um das Problem zu lösen. Hier seht ihr die RAM Kurve in Proxmox:

image
image1455×714 76.7 KB

Bisher hat meine Installation nur so um die 3GB benötigt, ich habe auch leider keinen genauen Zeitpunkt, seit wann das ganze auftritt, sodass ich auch nicht nachvollziehen kann, ob irgend ein Update einer Integration das Problem ist. Wirklich erinnern kann ich mich nur an zwei Automationen, die ich erstellt habe, diese habe ich testweise aber mal deaktiviert, um zu sehen, ob die den RAM volllaufen lassen.

Komischerweise kann ich aber auch eine sehr große Differenz zwischen HA und Proxmox RAM feststellen:

image
image1652×1031 83 KB

Ich habe wirklich alles versucht: AddOns löschen die ich nicht brauche, Integrationen deaktivieren, LOGS durchforsten (vielleicht aber die falschen?), Backup von letzter Woche einspielen, etc., aber alle Versuche bringen nichts. Hat irgendjemand eine Idee, bevor ich eine neue VM aufsetzte und das Backup mal auf eine neue VM einspiele? Neu Aufsetzten ist leider wirklich keine Möglichkeit, bzw. nur im Absoluten Notfall. Habe extra das Ganze auf Proxmox laufen, weil ich wirklich viel Smarthome habe :smiley:

Danke euch im Voraus!

__________________

  • InstallationsmethodeHome Assistant OS

  • Core: 2025.10.4

  • Supervisor: 2025.10.0

  • Operating System: 16.2

  • Frontend: 20251001.4

  • 2x CPU, 8GB RAM,

2

Proxmox kann nicht genau sagen wie viel RAM eine VM nutzt da ein VM nicht den gleichen Kernel nutzt wie Proxmox, Bei LXC’s hat Proxmox damit keine Probleme da die den Kernel von Proxmox nutzen.

Mein HA Ram Auslastung die Proxmox denkt:

grafik
grafik1288×333 48.7 KB

Die tatsächliche von HA:
grafik
grafik669×417 23.4 KB

hatten das Theme schon öffters.
Einfach die RAM anzeige in Proxmox ignorieren.

Was ist jetzt mit “HA reagiert im Frontend nicht mehr” im Titel, bin ich blind oder hast du das nicht wieder aufgegriffen?

Wenn du bei HA Probleme mit dem Frontend hast drück mal Strg + F5 um ohne Cache die Seite neu zu laden.

LG

1 „Gefällt mir“
3

Hey,

Sorry, da ich dachte, dass durch die RAM Problematik gefühlt meine Ursache lag, habe ich vergessen das Problem zu beschreiben :rofl:

Also tatsächlich geht zum Beispiel alles im Backend im Sinne von Automationen laufen, Geräte sind ansprechbar, etc.. auch die Menüführung funktioniert halb, aber nach einiger Zeit (dem Gefühl nach nach ca.2h) funktionieren die ganzen Oberflächen nur halb. Ich komme in die Einstellungen, kann aber z.B. nicht neu starten, nur über Proxmox. Kann Integrationen aufrufen, aber nicht richtig bedienen. Also sehr merkwürdig und wenig nachvollziehbar bzw. Kein Muster zu erkennen.

4

Das ließt sich eher nach eine defekten SD-Karte bei einer Raspi HA Installation. Was bei dir nicht sein kann. Trotzdem eine Möglichkeit deine Festplatte zu testen, bzw die Smart-Werte auszulesen?

Bei mir hat sich mal eine defekte SSD in einem Fujitsu Mini-PC so geäußert, das HA immer wieder willkürlich die CPU Auslastung auf 100% getrieben hat. Hat lange gedauert, bis ich den Fehler gefunden habe.

5

Ich kann dasselbe Problem bei HAOS auf einem Intel NUC beobachten.
Ich konnte ein Hardware Problem bereits ausschließen (hatte einen zweiten, baugleich NUC und bei dem habe ich dasselbe Fehlerbild).
Für mich sieht das wie ein Memory Leak aus aber ich konnte bisher nicht identifizieren, wer oder was dafür verantwortlich ist.

6

Hey,

aber dann müsten die anderen VM/Container doch ähnliche Probleme aufweisen? Paperless, EVCC, Unifi Server laufen alle ohne Probleme…

Muss mal gucken, ob Proxmox einen Hardware-Test anbietet.

7

Moin,

eigentlich wollte ich nichts dazu schreiben, denn das Thema RAM verbrauch in Linux war auch schon öfter Thema hier.

Wie kommt es zu einem erhöhten Verbrauch von RAM, es muss einen Auslöser dafür geben, in einer HA VM ist das oft dann, wenn ein HA internes Backup erstellt wird und zweitens, wenn ein Update, vom Core oder OS eingespielt wird, denn z. B. beim Erstellen eines Backups, müssen die zu sichernden Files erst einmal in den Speicher geladen werden, dort werden sie dann komprimiert, und dann auf das Medium, Platte oder Share, Cloud gespeichert, beim Einspielen von Updates, werden die Files erst im RAM ausgepackt, um dann ins Dateisystem geschrieben zu werden.
Linux, der Kernel, verwaltet das schon sehr effektiv, gerade für Dateioperationen wird RAM als Cache genutzt, wenn dann nach einiger Zeit das RAM nicht mehr genutzt wird, gibt der Kernel das RAM wieder frei, siehe Erläuterung,

Was dann zu einem Problem wird, denn in einer VM arbeitet ein eigenes Betriebssystem und das kommuniziert über den Guest Agend mit Proxmox, da gab/gibt es aber immer wieder Probleme, dass da nicht immer alles korrekt übermittelt wird, die passenden Diskussionen sind im Proxmox Forum zu finden.

Wenn dann auch noch das Balloonig in der VM genutzt wird, sieht es halt für Proxmox so aus, dass der Speicher wirklich der VM zugeordnet wurde, aber noch nicht wieder an Proxmox zurückgegeben wurde.

Dass bei Dir die Web-UI dann irgendwann nicht nutzbar ist, kann auch an dem Ressourcenmangel während der Operation zurückzuführen sein, ich würde als erstes erst einmal den Browser Cache leeren, einen anderen Browser nutzen, um zu sehen, ob es ein HA Problem ist, auch ein Blick in die Browser Konsole F12 kann da vielleicht helfen.

Das sind aber keine VMs oder?
Oder meinst Du das sie auf der gleichen SSD laufen, kann, muss aber nicht zu einem ähnlichen verhalten führen!

Wieso, Du siehst doch die S.M.A.R.T Werte der Laufwerke

grafik
grafik1259×702 144 KB

Zudem, wenn Du wirklich ein Test der SSD durchführen möchtest, geht das nicht, wenn die SSD / HDD gemountet ist, der Test für das Filesystem ist im übrigen

root@pve-10:~# fsck
fsck         fsck.btrfs   fsck.cramfs  fsck.ext2    fsck.ext3    fsck.ext4    fsck.fat     fsck.minix   fsck.msdos   fsck.vfat    fsck.xfs     fsck.zfs     
root@pve-10:~#

Auch das ist aber so, dass dieser Check beim Booten von Proxmox auf das Dateisystem angewendet wird, ein System, sollte es defekt sein, entweder repariert wird oder eben nicht gemountet wird, wenn eine Reparatur nicht möglich ist.

VG
Bernd

1 „Gefällt mir“
8

Hey,

also das RAM-Problem scheint plötzlich nicht mehr aufzutauchen, also der RAM läuft nicht mehr voll sondern ist jetzt konstant bei dem Wert, wie er vorher mal war.

Das Phänomän, dass Homeassistant irgendwann einfriert/teilweise nicht mehr benutzbar ist bleibt aber weiterhin auch nach dem laden eines Backups. Das würde dann eher auf ein Proxmox-Thema hinweisen, oder?

Werde die Tage mal die VM neu aufsetzten und da das Backup aufspielen, in der Hoffnung, das Problem verschwindet.

Die SMART Werte sind alle super…

Danke euch trotzdem schonmal für die Hilfe!

9

Moin,

was soll Proxmox mit der Web-UI von HA zu tun haben, oder sprichst Du von der Web-UI von Proxmox, sehr verwirrend das ist :wink:

genau, oder :wink:

Also schau mal in die Browserkonsole und zeige da mal die möglichen Fehler, ist denn ha noch an ping bar?
Kannst Du auf die Konsole in der VM, was gibt es denn für Logs?

In einem zweiten Fenster mal die Anzeige von Glances mitlaufen lassen, ist denn etwas da zu sehen, dass auf eine erhöhte CPU last, hinweist? Wie z. B. das von Deinem Bild

grafik
grafik586×102 22.3 KB

Auch mal das machen, was da steht, nämlich z drücken, damit man die ganze Liste angezeigt bekommt :slight_smile:

VG
Bernd

10

Hey,

nein, ich rede von der HA UI. Das “Backend” läuft normal, alle Automationen laufen, ich kann es pingen, etc.

Habe nun heute morgen mal eine komplett neue VM deployed mit HAOS und ein Backup eingespielt und siehe da, nach einer halben Stunde komme ich wieder nicht auf HA drauf. Habe nochmal die Logs durchgesucht und siehe da, es taucht ein Eintrag auf:

2025-10-27 08:30:49.769 ERROR (MainThread) [supervisor.jobs] Unhandled exception: [Errno 28] No space left on device
Traceback (most recent call last):
  File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 299, in wrapper
    return await method(obj, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/supervisor/supervisor/addons/addon.py", line 1400, in restore
    tmp, data = await self.sys_run_in_executor(_extract_tarfile)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/supervisor/supervisor/addons/addon.py", line 1386, in _extract_tarfile
    backup.extractall(
    ~~~~~~~~~~~~~~~~~^
        path=tmp.name,
        ^^^^^^^^^^^^^^
        members=secure_path(backup),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        filter="fully_trusted",
        ^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/local/lib/python3.13/tarfile.py", line 2355, in extractall
    self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      numeric_owner=numeric_owner,
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      filter_function=filter_function)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/tarfile.py", line 2464, in _extract_one
    self._handle_fatal_error(e)
    ~~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/usr/local/lib/python3.13/tarfile.py", line 2458, in _extract_one
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         set_attrs=set_attrs,
                         ^^^^^^^^^^^^^^^^^^^^
                         numeric_owner=numeric_owner,
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         filter_function=filter_function,
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         extraction_root=path)
                         ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/tarfile.py", line 2547, in _extract_member
    self.makefile(tarinfo, targetpath)
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/tarfile.py", line 2604, in makefile
    copyfileobj(source, target, tarinfo.size, ReadError, bufsize)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/tarfile.py", line 253, in copyfileobj
    dst.write(buf)
    ~~~~~~~~~^^^^^
OSError: [Errno 28] No space left on device

Das klingt ja nach einem Fehler der damit zu tun haben könnte, oder?

Galnces kann ich ja leider nicht mitlaufen lassen, da ja bei Problemauftritt die UI nur halb funktioniert, Glances leider gar nicht.

11

Ist scheinbar Deine Platte voll, oder wie muss man das interpretieren?

Wieviel Platz hat HA noch auf Deiner Platte?

12

Ja, korrekt, das müsste es sein, nur ist die bei weitem nicht voll:

image
image653×271 12.6 KB

Vor allem kein Plan, ob das auch der Auslöser war, da ich ja den Freeze der UI nie zeitlich genau beziffern kann….

13

2025-10-27 11-21-39
2025-10-27 11-21-39598×238 24.2 KB

Ähnlich wie bei mir.

Seltsam. Hast Du mal die Backups gelöscht und die Backupfunktion deaktiviert? Bzw. Backups nur nach “extern” geschoben…

Ich hatte mal ähnliche Probleme mit einer falsch konfigurierten MQTT-Verbindung. HA hat “alles gegeben” die Verbindung zu machen, ging halt nicht. Hat mein System extrem belastet. Habe ich dank GLANCES dann “gefunden”. Das sieht aber bei Dir “normal” aus.

14

Also ich weiß, dass es nur SMA-EM gibt, der über MQTT Daten verschickt.

Ansonsten habe ich noch diese Fehlermeldung gefunden:

2025-10-27 10:42:38.961 ERROR (MainThread) [supervisor.api.ingress] Ingress error: Cannot connect to host 172.30.32.1:62137 ssl:default [Connect call failed ('172.30.32.1', 62137)]
15

Moin,

warum erkläre ich da eigentlich alles so klein, klein, wenn dann doch keiner liest :wink:

Also, wenn man sich die Fehlermeldung und den Debug Output genauer anschaut, dann erkennt man, das das beim Auspacken des Backups passiert ist

2025-10-27 08:30:49.769 ERROR (MainThread) [supervisor.jobs] Unhandled exception: [Errno 28] No space left on device
..
File "/usr/src/supervisor/supervisor/addons/addon.py", line 1386, in _extract_tarfile
    backup.extractall(
..

Also was, wie auch immer Du Deine neue Instanz in Proxmox angelegt hast, da passt das aktuelle Backup nicht hinein!

Wenn 30 Minuten später erst das Problem mit der nicht erreichbaren Web-UI kommt, kann das auch nichts mit dem Fehler von 8:30 Uhr zu tun haben, es sei denn, das Auspacken lief genauso lange, dazu müsste man aber den genauen zeitlichen Ablauf kennen.
Wenn Du, nachdem es zu diesem Fehler gekommen ist, abwartest, bis das System aufgeräumt hat, dann sollte es auch wieder gehen.

Denn wie Du ja schon gezeigt hast, ist danach die Platte nicht voll

image
image653×271 12.6 KB

Wobei ich die Backups auch schleunigst aus der VM verbannen würde, macht alles nur unhandlich, zumal ein Proxmox Backup viel schneller wäre :wink:

Also der VM entweder mehr Speicher geben oder das Backup in kleinen Häppchen einspielen, erst Core usw, dann Add-ons, aber mit HA Backups kenne ich mich nicht aus, da ich sie nicht nutze.

VG
Bernd

16

Mir fiel dieses Argument von Dir schon einmal in einem anderem Post auf Bernd aber ich bin dennoch für mindestens 1 Proxmox unabhängiges HA Backup.

Konstellation am echten Beispiel
  • Letzte Woche gab es für Samba Share Addon ein fehlerhaftes Update.
  • Ich bemerkte es erst Stunden später, daß ich keinen Zugriff mehr hatte.
  • Der Weg, die vorige Addon Version wiederherzustellen, ging nur über ein HA Backup.
Nachteil Proxmox Restore

Ich hätte nach Bemerken des Fehlers die VM zwar superschnell zurückspielen können aber dann hätte ich alle Sensordaten bis dahin eingebüßt, da meine MariaDB als Addon in HA läuft.

Da hilft nur eins, MariaDB auch in eine VM umziehen :slight_smile:

17

Bernd hatte aber geschrieben

und ich vermute damit meint er eben auch das Backup eben nicht unter der HA VM zu speichern, sondern irgendwo an einem anderen Ort. Was ja auch Sinn macht, weil die Backup-Daten in der HA VM fressen nur unnötig Speicherplatz in der VM.

Ist halt auch so wie man seine HA Backups bei einer HA bare metal Install. ja auch nicht (unbedingt und schon lange nicht nur) auf der HA Kiste speichern sollte, sondern irgendwo extern.

HA_Speicher
HA_Speicher592×203 17.8 KB

Und meine HA Backups speicher ich extern auf einem NAS und einer externen USB HDD.

Ob dann ein HA Restore aus einem Proxmox Backup, oder auch aus einem HA Backup, schneller oder langsamer ist wäre noch zu klären. :laughing:

VG Jim

18

Bin auch dafür. Jedoch nicht auf dem Home Assistant Host. :wink: Ein NAS hat ja fast jeder Smarthome Enthusiast. :grin:

Gruß Osorkon

19

Stimmt, Bernd meinte aus der VM verbannen und nicht generell kein HA Backup machen.