Wer ein Homelab oder einen kleinen Homeserver auf Basis eines kompakten Rechners betreibt – vielleicht ein Intel NUC, ein gebrauchter ThinkCentre oder ein moderner Mini-PC mit N100-Prozessor – stößt fast immer auf dieselbe gläserne Decke: 8 GB Arbeitsspeicher. In der Theorie klingt das nach viel, besonders wenn man von der Windows- oder macOS-Welt kommt. Doch sobald Proxmox VE als Hypervisor installiert ist und das erste ZFS-Pool eingerichtet wurde, schlägt die Realität hart zu.

Man öffnet das Web-Interface, blickt auf das Dashboard und sieht einen RAM-Balken, der bedrohlich im roten Bereich bei 90 % oder mehr verharrt. Die Panik steigt: „Wie soll ich hier jemals eine Nextcloud, einen Webserver und ein Dokumentenmanagement-System gleichzeitig betreiben?“ Die gute Nachricht: Dein RAM ist nicht weg. Er wird nur falsch verwaltet. In diesem Deep-Dive-Guide zeige ich dir, wie wir die Kontrolle über den Arbeitsspeicher zurückgewinnen, ZFS in seine Schranken weisen und warum ein 8-GB-System mit dem richtigen Tuning performanter sein kann als ein schlecht konfiguriertes 32-GB-System.

Das ZFS-Paradoxon: Warum sicher auch teuer bedeutet

Bevor wir an den Stellschrauben drehen, müssen wir verstehen, wer der größte „Verbraucher“ in deinem System ist. Es ist nicht Proxmox selbst, und es sind meist auch nicht deine VMs. Es ist ZFS. ZFS ist mehr als nur ein Dateisystem; es ist ein Logical Volume Manager und ein RAID-Controller in einem. Es bietet Features wie Copy-on-Write, Snapshots auf Blockebene und eine unglaubliche Datensicherheit durch Prüfsummen.

Damit ZFS diese Sicherheit und Geschwindigkeit garantieren kann, nutzt es den Adaptive Replacement Cache (ARC). Der ARC ist ein extrem intelligenter Cache-Mechanismus, der versucht, so viele Daten wie möglich im RAM vorzuhalten, um den Zugriff auf die (langsamen) physischen Festplatten zu minimieren. Der ARC unterscheidet dabei zwischen Most Recently Used (MRU) und Most Frequently Used (MFU) Daten.

Das Problem der Standardkonfiguration

Das Problem ist die Philosophie von ZFS: „Freier RAM ist verschwendeter RAM.“ Daher ist ZFS standardmäßig so konfiguriert, dass es sich bis zu 50 % des verfügbaren Arbeitsspeichers reserviert. Auf einem 8-GB-Node sind das sofort 4 GB. Wenn man bedenkt, dass der Linux-Kernel und die Proxmox-Dienste ebenfalls ca. 1,5 GB benötigen, bleibt für deine eigentlichen Anwendungen kaum noch Luft. Wenn nun eine VM (wie deine Nextcloud) plötzlich RAM anfordert, muss ZFS den ARC verkleinern. Dieser Prozess ist zwar dynamisch, aber oft nicht schnell genug, was zu merklichen Rucklern (Lags) oder dem gefürchteten Out-of-Memory (OOM) Killer führt, der einfach Prozesse abschießt, um den Host zu retten.

Die chirurgische Lösung: Das ZFS ARC Limit manuell setzen

Um Stabilität in ein 8-GB-System zu bringen, müssen wir ZFS ein festes Budget zuweisen. Wir haben uns in unserem Setup für ein Limit von 1 GB entschieden. Das klingt radikal wenig, ist aber für ein Homelab mit SSD-Speicher absolut ausreichend, da die Zugriffszeiten der SSDs den kleineren Cache kompensieren.

Die mathematische Grundlage für die Konfiguration ist die Umrechnung von Gigabyte in Bytes. Da der Kernel mit Bytes arbeitet, nutzen wir folgende Formel:

$$1 \text{ GB} = 1024 \times 1024 \times 1024 = 1.073.741.824 \text{ Bytes}$$

Die Umsetzung auf der Konsole:

Wir erstellen eine Konfigurationsdatei im Verzeichnis /etc/modprobe.d/. Dieser Ort ist entscheidend, da hier Parameter für Kernel-Module (wie das ZFS-Modul) definiert werden, bevor diese geladen werden.

# Konfigurationsdatei erstellen oder bearbeiten
nano /etc/modprobe.d/zfs.conf

# Folgende Zeile einfügen (für 1GB Limit)
options zfs zfs_arc_max=1073741824

# WICHTIG: Die Änderungen müssen in das Boot-Image übernommen werden
update-initramfs -u -k all

Nach einem Neustart wird dein System den ARC niemals über diese Grenze wachsen lassen. Dein Dashboard wird plötzlich wieder 3-4 GB freien Speicher anzeigen – Platz, den du nun effektiv deinen VMs zuweisen kannst.

Kernel-Tuning: Swappiness und I/O-Management

Wenn wir über RAM reden, müssen wir auch über Swap reden. Swap ist der Bereich auf deiner Festplatte, den Linux nutzt, wenn der echte RAM voll ist. Auf einem Server mit 8 GB ist Swap lebensnotwendig, aber die Art und Weise, wie Linux ihn nutzt, ist oft kontraproduktiv für Web-Apps.

Der Swappiness-Faktor

Der Parameter vm.swappiness definiert, wie „gerne“ der Kernel Daten aus dem RAM in den Swap schiebt. Ein Wert von 60 (Standard) bedeutet, dass Linux schon bei moderater Auslastung anfängt zu swappen. Da Festplatten (selbst NVMe-SSDs) um Faktoren langsamer sind als RAM, führt das zu Latenzen. Wir senken diesen Wert auf 10.

# Wert temporär ändern
sysctl vm.swappiness=10

# Dauerhaft speichern in /etc/sysctl.conf
echo "vm.swappiness=10" >> /etc/sysctl.conf

Ein Wert von 10 sagt dem Kernel: „Nutze den teuren RAM so lange wie möglich und lagere nur im absoluten Notfall aus.“ Dies verbessert die Antwortzeiten deiner Nextcloud-Instanz spürbar, da PHP-Worker und Datenbank-Threads seltener auf die Festplatte warten müssen.

KSM: Der kostenlose RAM-Riegel per Software

Ein Feature, das oft nur in Enterprise-Umgebungen diskutiert wird, aber für 8-GB-Homelabs ein echter Gamechanger ist, heißt Kernel Samepage Merging (KSM). Wenn du – wie in unserem Fall – mehrere Linux-VMs betreibst (z. B. Debian für den Webserver und Ubuntu für die Nextcloud), laden diese VMs viele identische Daten in den RAM: Kernel-Bibliotheken, Bash-Binaries oder Python-Runtimes.

KSM scannt den Arbeitsspeicher im Hintergrund nach identischen Speicherseiten (Pages). Wenn es zwei identische Seiten findet, führt es diese zu einer einzigen Seite zusammen und markiert sie als „Copy-on-Write“. Beide VMs „denken“, sie hätten ihren eigenen Speicherbereich, teilen sich aber physisch denselben RAM-Riegel. In unserem Setup konnten wir durch KSM effektiv ca. 800 MB bis 1,2 GB RAM einsparen. Das ist fast so viel, wie wir ZFS weggenommen haben!

Du findest den Status in Proxmox unter dem Reiter „Summary“ deiner Node. Dort siehst du den Wert „KSM sharing“ – je höher diese Zahl, desto mehr RAM hast du virtuell „dazugewonnen“.

Warum Storage-Hygiene deinen RAM rettet (fstrim)

Man fragt sich oft: Was hat der freie Platz auf der Festplatte mit dem Arbeitsspeicher zu tun? Die Antwort lautet: Caching-Effizienz. Wenn deine VMs (wie die Nextcloud) viele temporäre Dateien schreiben (Previews, Caches, Logs) und diese wieder löschen, bleibt der Platz auf der Ebene des Hypervisors oft als „belegt“ markiert. Das nennt man Filesystem Bloat.

Wenn du nun ein Backup machst oder ZFS Daten verschieben muss, versucht das System, diese „gelöschten“ Daten im RAM-Cache zu halten, weil es nicht weiß, dass sie wertlos sind. Wir haben durch das Kommando fstrim -av innerhalb unserer VMs über 200 GB an Geisterdaten freigegeben. Das entlastet nicht nur die SSD, sondern sorgt auch dafür, dass der RAM-Cache des Hosts nicht mit Datenmüll verstopft wird.

Wichtiger SEO-Hinweis für Admins: Aktiviere in den Proxmox-Hardware-Einstellungen deiner VMs bei jeder Disk die Option Discard. Nur so weiß die VM, dass sie den Trim-Befehl an den Proxmox-Host weiterreichen darf.

Monitoring: Dashboard-Werten richtig vertrauen

Nach all diesen Optimierungen wirst du im Proxmox-Dashboard vielleicht immer noch Werte um die 70-80 % sehen. Hier ist es wichtig, die Linux-Speicherverwaltung richtig zu lesen. Linux unterscheidet zwischen:

• Used: RAM, der wirklich von Programmen belegt ist.
• Buffers/Cache: RAM, den Linux für Dateioperationen nutzt, den es aber sofort freigibt, wenn eine Applikation ihn braucht.

Das Proxmox-Dashboard zählt den Cache oft mit. Schau stattdessen lieber mit dem Befehl free -h auf der Konsole nach. Die Spalte „available“ ist die einzige Zahl, die wirklich zählt. Wenn dort bei einem 8-GB-System noch mehr als 1 GB steht, hast du alles richtig gemacht.

Fazit und Ausblick

Ein Proxmox-Server mit 8 GB RAM ist kein Spielzeug, sondern ein ernstzunehmendes Werkzeug – man muss nur wissen, wie man die Ressourcen-Gier moderner Dateisysteme bändigt. Durch die Kombination aus ZFS ARC Limitierung, Swappiness-Tuning und KSM-Nutzung haben wir ein System geschaffen, das stabil drei produktive VMs hostet, ohne jemals ins Schwitzen zu geraten.

Doch RAM-Optimierung ist nur die halbe Miete. Im nächsten Teil unserer Serie schauen wir uns an, warum wir trotz dieser Erfolge unsere Nextcloud-Datenstruktur radikal umgebaut haben. Wir zeigen dir, wie man System und Daten auf getrennten virtuellen Disks verwaltet, um Backups schneller und die Wiederherstellung sicherer zu machen. Neugierig? Hier geht es zum nächsten Beitrag: Nextcloud Data Migration – Warum du System und Daten trennen musst.