Wie viel RAM braucht ein Server? Gemessen statt geraten (2026)

Wie viel RAM braucht ein Server? Die ehrliche Antwort lautet: weniger, als dir die meisten Tabellen sagen — und du kannst es nicht ausrechnen, ohne zu messen. Denn die Zahl, die fast jeder für „Speicherverbrauch” hält, ist die falsche. Wir haben das 2026 auf drei eigenen Produktivmaschinen nachgemessen: einem Entwicklungsserver mit 24 GB, einem kleinen VPS mit 8 GB und einem Shopware-Produktivserver mit 64 GB.

Der Befund, der alles andere überschattet: Auf dem Shopware-Server summieren sich 43 PHP-Worker auf 11.245 MB RSS. Ihr tatsächlicher Speicherverbrauch beträgt 893 MB. Wer nach der üblichen Methode „RSS addieren” dimensioniert, kauft hier das Zwölffache dessen, was die Maschine braucht.

Wie viel RAM braucht ein Server: die kurze Antwort

Wenn du nur eine Zeile mitnimmst, dann diese: Miss available, nicht free, und summiere PSS, nicht RSS. Alles andere in diesem Artikel ist die Begründung dafür.

Als grobe Einstiegsgrößen, jeweils mit den Werten, die wir weiter unten belegen:

Diese Tabelle ist ein Startpunkt, kein Ergebnis. Der eigentliche Punkt ist: Nach zwei Wochen Betrieb kannst du die Frage selbst beantworten — und zwar besser als jede Tabelle, weil deine Last deine Last ist.

Der erste Fehler: „free” ist die falsche Spalte

Der Klassiker. Jemand schaut auf free -m, sieht wenig freien Speicher und bestellt mehr RAM. Hier ist der echte Zustand unseres Entwicklungsservers zum Zeitpunkt der Messung:

               total        used        free      shared  buff/cache   available
Mem:           23456        6125        1380          78       16428       17331

1.380 MB frei bei 23.456 MB gesamt. Das sieht nach 94 % Auslastung aus. Panik wäre die naheliegende Reaktion — und sie wäre komplett falsch. Die richtige Spalte steht ganz rechts: 17.331 MB verfügbar. Das sind 74 % der Maschine.

Der Unterschied sind die 16.428 MB unter buff/cache. Das ist der Page Cache: Dateien, die der Kernel im Speicher vorhält, weil er ihn sonst ungenutzt herumliegen lassen müsste. Dieser Speicher ist nicht verbraucht, er ist verliehen. Sobald ein Programm ihn braucht, bekommt es ihn.

Der Beweis: Cache leeren und zusehen

Wir haben das nicht behauptet, sondern gemessen. Eine 1,5-GB-Datei erzeugt, Cache geleert, zweimal gelesen:

Zwei Dinge stehen in dieser Tabelle:

Erstens: free sprang von 1.205 auf 17.243 MB — eine Vervierzehnfachung. available bewegte sich dabei von 17.340 auf 17.610 MB, also um 1,5 %. Die Maschine hatte die ganze Zeit denselben nutzbaren Speicher. Nur eine der beiden Spalten hat das gewusst.

Zweitens — und das ist der Preis: Das erste Lesen der Datei dauerte 1,18 Sekunden, das zweite 0,24 Sekunden. Der Cache war fast fünfmal schneller. Wer „Speicher freiräumt”, indem er den Cache leert, kauft sich eine schönere Zahl in free und bezahlt sie mit Plattenzugriffen.

Merksatz: Ein Linux-Server mit viel freiem Speicher nutzt seinen Speicher nicht. free nahe null ist kein Alarm, sondern ein funktionierendes System.

Der zweite Fehler: VSZ ist keine Speichermessung

ps zeigt zwei Spalten, die nach Speicher aussehen: VSZ (virtueller Speicher) und RSS (resident, also tatsächlich im RAM). Wie weit die auseinanderliegen können, zeigt unsere MariaDB-Instanz auf dem Entwicklungsserver:

Acht Terabyte virtueller Adressraum auf einer Maschine mit 24 Gigabyte RAM. Das ist kein Fehler und kein Speicherleck — es ist die Art, wie moderne Programme mit Adressen umgehen. Der Gegencheck über smaps_rollup bestätigt den realen Anteil:

Rss:               24368 kB
Pss:               24364 kB
Private_Dirty:     15508 kB
Private_Clean:      8856 kB

Tatsächlich im RAM: 23,7 MiB, davon 15 MiB wirklich exklusiv dieser Datenbank.

Warum das so ist — nachgestellt in vier Schritten

Damit das nicht Theorie bleibt, haben wir ein kleines Programm geschrieben, das 2 GiB anfordert und sie dann stückweise wirklich benutzt:

Die zweite Zeile ist der ganze Punkt: Die Anforderung von 2 GiB hat den RSS um 0,2 MiB erhöht. Der Kernel hat nichts weiter getan, als eine Zusage zu machen. Erst das Beschreiben einer Seite kostet echten Speicher — und dann exakt so viel, wie beschrieben wurde.

Das erklärt auch, warum Committed_AS auf unserem Server bei 20,2 GiB liegt, während das CommitLimit 15,5 GiB beträgt. Linux hat mehr zugesagt, als es hat, weil es weiß, dass niemand alles gleichzeitig einfordert. Das nennt sich Overcommit und steht bei uns mit vm.overcommit_memory = 0 auf der Standardeinstellung.

Der dritte Fehler — und der teuerste: RSS addieren

Jetzt kommt der Punkt, an dem die meisten Dimensionierungen kippen. Die naheliegende Methode lautet: RSS aller Prozesse addieren, Puffer drauf, fertig. Auf unserem Entwicklungsserver ergibt das:

Fast drei Gigabyte Luft in einer Rechnung, die korrekt aussieht. Der Grund: RSS zählt geteilte Seiten bei jedem Prozess voll mit. Eine Bibliothek, die 40 Prozesse gemeinsam nutzen, erscheint vierzigmal. PSS (Proportional Set Size) teilt solche Seiten durch die Zahl der Nutzer und ist deshalb die einzige Summe, die man bilden darf.

Auf dem Produktivserver wird daraus ein Faktor 12,6

Auf dem Entwicklungsserver sind es 55 % Aufschlag. Auf dem Shopware-Server mit seinen vielen gleichartigen PHP-Prozessen wird daraus etwas ganz anderes:

43 Worker teilen sich denselben PHP-Interpreter, dieselben Erweiterungen, denselben OPcache. Jeder einzelne meldet das komplette geteilte Fundament als „seinen” Speicher. Wer hier nach der Faustformel „261 MB pro Worker × geplante Worker” rechnet, dimensioniert eine Maschine für 11 GB, wo 0,9 GB gebraucht werden.

So misst du PSS selbst:

# Echter Verbrauch einer Prozessfamilie (hier php-fpm)
T=0; for p in $(pgrep -f php-fpm); do
  v=$(awk '/^Pss:/{print $2; exit}' /proc/$p/smaps_rollup 2>/dev/null)
  T=$((T+${v:-0}))
done; echo "PSS gesamt: $((T/1024)) MiB"

Und zum Gegenprüfen der Gesamtsumme:

ps -eo rss --no-headers | awk '{s+=$1} END {print "RSS-Summe: "int(s/1024)" MiB"}'

Liegen beide Zahlen weit auseinander, hast du viele gleichartige Prozesse — und die RSS-Zahl ist wertlos für die Dimensionierung.

Was einzelne Dienste wirklich brauchen — unsere Zahlen

Statt Faustregeln abzuschreiben, hier die per systemd gemessenen Werte unserer laufenden Dienste. Das ist der cgroup-Wert, also inklusive aller Kindprozesse und des zugehörigen Caches:

Zwei Ablesungen daraus:

Ein Reverse Proxy ist billig. Caddy bedient bei uns über dreißig Domains mit automatischem TLS für 104 MB. Wer nur statische Seiten und Weiterleitungen braucht, kommt mit 1 GB Gesamt-RAM aus. Details dazu in unserem Artikel über Nginx als Reverse Proxy und der Einführung Was ist ein Reverse Proxy?.

Die JVM ist die teuerste Zeile der Liste. signal-cli braucht allein mehr als sechs unserer Node-Dienste zusammen. Sprachlaufzeit schlägt Funktionsumfang.

Und die Container dazu, gemessen mit docker stats:

Sechs Container zusammen: 465 MB. Der Docker-Daemon selbst kostet mit 179 MB mehr als die vier kleinsten Container zusammen. Wenn du Docker einsetzt, rechne den Daemon als eigenen Posten ein — er ist da, auch wenn nichts läuft. Wie wir Container betreiben, steht im Artikel zu Docker Compose.

Der eine Dienst, bei dem die Faustregeln stimmen: die Datenbank

Auf dem Shopware-Produktivserver sieht die Rangliste völlig anders aus:

34 GB für die Datenbank auf einer 64-GB-Maschine. Und anders als bei php-fpm ist diese Zahl echt — denn der InnoDB Buffer Pool ist auf 24 GiB konfiguriert, und genau das ist der Zweck einer Datenbank: Daten im RAM halten, statt sie von der Platte zu lesen.

Das ist die wichtigste Unterscheidung des ganzen Artikels: Bei Anwendungsprozessen ist viel Speicher oft nur eine Messillusion. Bei Datenbanken ist er der Sinn der Sache. Der Buffer Pool ist keine Verschwendung, die man wegoptimiert — er ist der Grund, warum der Shop schnell ist. Redis meldet dazu 263 MB genutzt bei einem maxmemory von 8 GB, hat also noch reichlich Luft.

Swap: kein Notnagel, sondern Auslagerung

Swap hat einen schlechten Ruf, der aus einer falschen Vorstellung stammt: „Swap ist, was passiert, wenn der RAM alle ist.” Unsere Messung sagt etwas anderes. Der Entwicklungsserver:

Swap:           4095        3949         146

3.949 von 4.095 MB Swap belegt — bei gleichzeitig 17.331 MB verfügbarem RAM. Nach der Notnagel-Theorie dürfte das nicht existieren. Der Grund steht in vm.swappiness = 60: Der Kernel lagert Seiten aus, die lange nicht angefasst wurden, um Platz für Page Cache zu schaffen — auch wenn RAM frei wäre. Das ist kein Mangel, das ist Hausputz.

Wer liegt bei uns im Swap?

Das sind überwiegend Prozesse, die beim Start viel initialisiert haben und seitdem nur einen Bruchteil davon benutzen. Diese Seiten auf der Platte zu parken ist die richtige Entscheidung.

Die Zahl, die wirklich zählt: Memory Pressure

Ob Swap ein Problem ist, sagt dir weder seine Größe noch sein Füllstand. Es sagt dir PSI (Pressure Stall Information), verfügbar seit Kernel 4.20:

cat /proc/pressure/memory

Unsere drei Maschinen im Vergleich:

Der Wert some avg60 gibt an, welcher Anteil der letzten 60 Sekunden mindestens ein Prozess auf Speicher warten musste. Die Faustregel aus unserem Betrieb:

• unter 1 — alles in Ordnung, kein Handlungsbedarf
• 1 bis 10 — es beginnt zu ruckeln, beobachten
• über 10 — echter Mangel, jetzt RAM nachlegen
• full dauerhaft über 0 — das System kommt nicht mehr hinterher

Der Entwicklungsserver ist der lauteste der drei — mit 0,23. Das heißt: Selbst die Maschine, deren Swap zu 96 % voll ist, hat praktisch keinen Speicherdruck. Ein voller Swap ist kein Alarm. Ein hoher PSI-Wert ist einer.

Der OOM-Killer: was passiert, wenn es doch knapp wird

Wenn Linux wirklich keinen Speicher mehr auftreiben kann, greift der Out-of-Memory-Killer. Er beendet einen Prozess — und zwar nicht zwingend den, der schuld ist, sondern den mit der höchsten Punktzahl aus Speicherverbrauch und oom_score_adj. In der Praxis trifft es oft die Datenbank, weil sie am meisten Speicher hält.

Auf unseren Maschinen ist das seit 82 Tagen Laufzeit kein einziges Mal passiert:

journalctl -k | grep -ci "out of memory\|oom-kill"
# → 0

Wie du prüfst, ob es dich getroffen hat:

# Kernel-Log nach OOM-Ereignissen durchsuchen
journalctl -k --no-pager | grep -i "oom-kill\|Out of memory: Killed"

# Wie gefährdet ist ein bestimmter Prozess?
cat /proc/$(pgrep -x mariadbd)/oom_score

Einen wichtigen Dienst kannst du schützen, indem du ihm über systemd eine niedrigere Bewertung gibst — dann trifft es im Zweifel jemand anderen:

# /etc/systemd/system/meindienst.service.d/oom.conf
[Service]
OOMScoreAdjust=-500

Ein Detail, das viele übersehen: systemd-oomd ist auf unserem System inaktiv. Es gibt also keine zweite Instanz, die vor dem Kernel eingreift. Prüfe das bei dir mit systemctl is-active systemd-oomd — wenn es aktiv ist, kann es Dienste beenden, bevor der Kernel überhaupt in Bedrängnis kommt, und zwar auf Basis von PSI-Werten.

Der Posten, den fast jede Rechnung vergisst: der Kernel selbst

Bevor die erste Anwendung startet, hat sich das Betriebssystem bereits bedient. Auf unserem Entwicklungsserver:

Dreiviertel Gigabyte, bevor irgendetwas Nützliches läuft. Davon sind 2.568 MB des Slab-Anteils als SReclaimable zurückholbar — aber der Rest ist fest. Dazu kommt bei uns noch das Journal mit 1.008,9 MB auf der Platte, das zwar keinen RAM kostet, aber gern vergessen wird, wenn es um Dimensionierung geht.

Praktische Konsequenz: Auf einem 1-GB-VPS bleiben dir nach Kernel und Grunddiensten realistisch 500–600 MB für deine Anwendung. Deshalb ist 1 GB nur für wirklich schlanke Aufgaben sinnvoll.

Die drei Maschinen im direkten Vergleich

Alle Werte am selben Tag erhoben:

Die interessanteste Zeile ist die Swap-Zeile. Der Produktivserver hat 16 GB Swap eingerichtet und nutzt davon 8 MB — also 0,05 %. Der Entwicklungsserver nutzt 96 % seines Swaps. Beide haben PSI-Werte nahe null. Das zeigt sehr deutlich: Swap-Nutzung korreliert nicht mit Speichermangel. Der Produktivserver hat einfach so viel RAM, dass der Kernel nie einen Grund zum Auslagern hatte.

Und noch etwas: Der Produktivserver ist mit 58 % die am stärksten ausgelastete Maschine — und meldet trotzdem null Speicherdruck. 58 % ist ein sehr gesunder Betriebspunkt. Wer Server auf 20 % Auslastung fährt, bezahlt Kapazität, die er nie abruft.

So beantwortest du die Frage für deinen eigenen Server

Hier ist das Verfahren, das wir selbst benutzen. Es braucht zwei Wochen Betrieb und fünf Befehle.

Schritt 1 — die richtige Spalte lesen:

free -m
# Nur 'available' zählt. 'free' ignorieren.

Schritt 2 — Speicherdruck über die Zeit beobachten:

cat /proc/pressure/memory
# 'some avg300' unter 1 = alles gut

Schritt 3 — echten Verbrauch pro Dienst ermitteln:

systemctl status DIENSTNAME | grep Memory
# oder für alle auf einmal:
systemd-cgtop -m --iterations=1

Schritt 4 — die Prozessfamilien-Falle prüfen:

# RSS-Summe (überschätzt) gegen PSS-Summe (echt)
ps -eo rss --no-headers | awk '{s+=$1} END {print "RSS: "int(s/1024)" MiB"}'
T=0; for f in /proc/[0-9]*/smaps_rollup; do
  v=$(awk '/^Pss:/{print $2; exit}' "$f" 2>/dev/null); T=$((T+${v:-0}))
done; echo "PSS: $((T/1024)) MiB"

Schritt 5 — Spitzen statt Momentaufnahmen:

Ein einzelnes free -m zeigt dir eine Sekunde. Interessant ist der schlechteste Moment der letzten zwei Wochen. Dafür brauchst du eine Aufzeichnung — entweder sar aus dem Paket sysstat oder eine simple cron-Zeile:

*/5 * * * * echo "$(date +\%F\ \%H:\%M) $(awk '/MemAvailable/{print $2}' /proc/meminfo)" >> /var/log/mem-verlauf.txt

Nach zwei Wochen weißt du, wie tief available wirklich gefallen ist. Diese Zahl, nicht die Tabelle oben, beantwortet deine Frage.

Die Regel, nach der wir aufrüsten

Wir legen RAM nach, wenn eine dieser Bedingungen über mehrere Tage erfüllt ist:

1. available fällt unter 15 % des Gesamtspeichers
2. PSI some avg300 liegt dauerhaft über 1
3. Der OOM-Killer war aktiv — auch nur ein einziges Mal
4. Die Datenbank kann ihren Buffer Pool nicht auf die Größe der heißen Daten setzen

Was kein Grund zum Aufrüsten ist: ein niedriger free-Wert, ein voller buff/cache, belegter Swap, oder eine hohe RSS-Summe.

Was wir bewusst nicht behaupten

Zur Ehrlichkeit gehört, wo unsere Messung aufhört.

Desktop- und VM-Szenarien haben wir nicht gemessen. Auf unseren Maschinen fehlt /dev/kvm; wir können keine virtuellen Maschinen betreiben und damit auch nicht messen, wie sich Ballooning oder KSM-Deduplizierung bei mehreren VMs auswirken. Wer über Virtualisierung nachdenkt, findet einen Einstieg in unserem Vergleich Proxmox vs ESXi — aber die RAM-Zahlen dort sind nicht von uns gemessen.

zram haben wir nicht im Einsatz. Auf keiner der drei Maschinen läuft komprimierter Swap im RAM. Wir können deshalb nicht aus eigener Erfahrung sagen, wie viel das auf kleinen VPS bringt. Die Technik ist real und wird gern empfohlen — von uns bekommst du dazu keine Zahl, weil wir keine haben.

Windows-Server haben wir nicht angefasst. Alle Werte stammen von Linux-Systemen.

Eine abgeschriebene Zahl sieht in einer Tabelle identisch aus wie eine gemessene. Deshalb steht hier lieber eine Lücke als eine Schätzung.

Fazit: Wie viel RAM braucht ein Server?

Die Frage wie viel RAM ein Server braucht lässt sich nicht aus einer Tabelle ablesen, weil die verbreiteten Messmethoden systematisch in eine Richtung falsch liegen: Sie überschätzen. RSS zählt geteilte Seiten mehrfach, VSZ misst Zusagen statt Verbrauch, und free behandelt nützlichen Cache wie verlorenen Speicher.

Die drei Zahlen, die aus unserer Messung hängen bleiben:

• 12,6 × — so stark überschätzt die RSS-Summe den Verbrauch von 43 PHP-Workern
• 352.602 × — so weit liegen VSZ und RSS bei unserer MariaDB auseinander
• 0,23 — der höchste Speicherdruck auf drei Produktivmaschinen, also praktisch keiner

Praktisch heißt das: Kaufe klein, miss zwei Wochen, rüste auf, wenn available und PSI es sagen. Ein 4-GB-Server, der zu 58 % ausgelastet läuft und null Speicherdruck meldet, ist richtig dimensioniert. Ein 32-GB-Server mit 20 % Auslastung ist ein Dauerauftrag an deinen Hoster.

Die einzige Ausnahme bleibt die Datenbank. Dort ist Speicher kein Verbrauch, sondern Leistung: Der Buffer Pool soll so groß sein, dass die aktiv genutzten Daten hineinpassen. Alles darüber ist verschenkt, alles darunter kostet dich Plattenzugriffe bei jeder Anfrage.

Wenn du deinen Server neu aufsetzt, hilft dir unser Leitfaden Linux-Server einrichten weiter; bei der Wahl der Distribution unser Überblick der Linux-Server-Distributionen. Und wenn du überlegst, KI-Modelle selbst zu betreiben — das ist der eine Fall, in dem die Speicherfrage tatsächlich vor der Anschaffung entschieden wird: Lokale KI betreiben.

Häufige Fragen

Wie viel RAM braucht ein Server mindestens?

Ein reiner Reverse Proxy oder Webserver für statische Seiten läuft stabil mit 1 GB. Unser Caddy bedient über 30 Domains mit TLS für 104 MB. Rechne aber ein, dass Kernel und Grunddienste auf unserem System bereits 767 MB an festen Strukturen belegen — auf einem 1-GB-VPS bleiben dir realistisch 500 bis 600 MB für die eigene Anwendung.

Warum zeigt mein Server fast keinen freien Speicher an?

Weil Linux ungenutzten Speicher als Page Cache verwendet. Unser Entwicklungsserver meldete 1.380 MB free, aber 17.331 MB available — der Unterschied sind 16.428 MB Dateicache, die jederzeit zurückgegeben werden. Schau immer auf die Spalte available, nicht auf free. Ein Server mit viel freiem Speicher nutzt seinen Speicher schlicht nicht.

Was ist der Unterschied zwischen VSZ und RSS?

VSZ ist der virtuelle Adressraum, also alles, was ein Prozess angefordert hat. RSS ist der Teil, der tatsächlich im RAM liegt. Bei unserer MariaDB stehen 8,00 TiB VSZ gegen 23,7 MiB RSS — Faktor 352.602. Für die Dimensionierung ist VSZ komplett unbrauchbar.

Kann ich einfach die RSS-Werte aller Prozesse addieren?

Nein, und das ist der teuerste Fehler bei der Dimensionierung. RSS zählt geteilte Speicherseiten bei jedem Prozess voll mit. Bei 43 php-fpm-Workern auf unserem Produktivserver ergab die RSS-Summe 11.245 MB, der tatsächliche Verbrauch lag bei 893 MB — eine Überschätzung um das 12,6-Fache. Summiere stattdessen PSS aus /proc/PID/smaps_rollup.

Ist belegter Swap ein Zeichen für zu wenig RAM?

Nein. Unser Entwicklungsserver hat 96 % seines Swaps belegt und gleichzeitig 17 GB verfügbaren RAM. Der Kernel lagert bei vm.swappiness = 60 selten genutzte Seiten aus, um Platz für Cache zu schaffen. Ob echter Mangel herrscht, sagt dir /proc/pressure/memory — nicht der Swap-Füllstand.

Wie erkenne ich, dass mein Server wirklich zu wenig RAM hat?

An drei Signalen: available fällt dauerhaft unter 15 % des Gesamtspeichers, der PSI-Wert some avg300 in /proc/pressure/memory liegt über 1, oder der OOM-Killer war aktiv. Auf unseren drei Maschinen lag der höchste PSI-Wert bei 0,23, und in 82 Tagen Laufzeit gab es null OOM-Ereignisse.

Wie viel RAM braucht ein Server für einen Onlineshop?

Rechne ab 16 GB, und der größte Posten ist die Datenbank. Auf unserem Shopware-Produktivserver belegt MariaDB 34 GB, davon 24 GiB konfigurierter InnoDB Buffer Pool. Anders als bei Anwendungsprozessen ist dieser Speicher kein Messfehler, sondern der Zweck: Daten im RAM statt auf der Platte. Die 43 PHP-Worker daneben brauchen zusammen nur 893 MB.

Was passiert, wenn der Server keinen Speicher mehr hat?

Der Kernel startet den OOM-Killer und beendet einen Prozess — nicht unbedingt den Verursacher, sondern den mit der höchsten Bewertung aus Speicherverbrauch und oom_score_adj. Oft trifft es die Datenbank. Wichtige Dienste schützt du per systemd mit OOMScoreAdjust=-500. Prüfe zusätzlich, ob systemd-oomd aktiv ist — es greift schon vor dem Kernel ein.

Wie viel RAM verbraucht Docker?

Der Docker-Daemon allein belegt auf unserem Server 179 MB, bevor ein einziger Container läuft. Unsere sechs produktiven Container kommen zusammen auf 465 MB, von 5,9 MB für eine kleine Datenbank bis 221,9 MB für eine WordPress-Instanz. Plane den Daemon als eigenen Posten ein.

Sollte ich den Cache leeren, um Speicher freizugeben?

Nein. Wir haben es gemessen: Nach drop_caches sprang free von 1.205 auf 17.243 MB, aber available änderte sich nur um 1,5 % — es wurde also kein nutzbarer Speicher gewonnen. Bezahlt hast du trotzdem: Das Lesen derselben Datei dauerte danach 1,18 statt 0,24 Sekunden, war also fast fünfmal langsamer.