Ein Server, sieben Dienste, 7,7 GB RAM
Auf einer einzigen Maschine mit 7,7 GB Arbeitsspeicher laufen bei mir: Nextcloud, GitLab, n8n, YouTrack, eine Vektordatenbank, ein Minecraft-Server und der nginx, der das alles nach außen verteilt. Das ist keine Empfehlung. Es ist ein Erfahrungsbericht darüber, was in so einem Aufbau zuerst knapp wird – und es ist nicht das, was man erwartet.
Die Zahlen
Ein Blick auf die aktuelle Verteilung:
GitLab 3535 MB
YouTrack 1680 MB
n8n 668 MB
MariaDB 97 MB
PHP-FPM 79 MBGesamt sind 6,0 von 7,7 GB belegt, 1,2 GB tatsächlich verfügbar, 1,6 GB liegen im Swap.
Zwei Dienste verbrauchen zusammen 5,2 GB – also mehr als zwei Drittel. Und es sind ausgerechnet die beiden, die man auf so einer Maschine am ehesten für selbstverständlich hält.
GitLab ist kein Dienst, GitLab ist eine Plattform
3,5 GB für die Versionsverwaltung sind kein Fehler in der Installation, sondern die Bauart. Unter der Oberfläche laufen ein Ruby-Webserver mit mehreren Arbeitsprozessen, ein Hintergrundverarbeiter, eine PostgreSQL, ein Redis, ein eigener Git-Dienst und ein Prozessverwalter, der das zusammenhält. Es ist eine vollständige Entwicklungsplattform mit Ticketverwaltung, Registry und CI – und die bezahlt man mit Speicher, auch wenn man nur Repositories ablegen will.
Wer wirklich nur Git braucht, kommt mit Forgejo oder Gitea auf einen Bruchteil. Das ist die Umstellung, die ich mir am ehesten vornehmen würde – und der einzige Grund, warum sie noch nicht passiert ist, heißt CI-Pipelines, die ich nicht anfassen will.
YouTrack wiederum ist eine Java-Anwendung, und 1,7 GB sind für eine JVM mit Standardeinstellungen nichts Ungewöhnliches. Dort ließe sich über die Heap-Größe nachjustieren, mit dem üblichen Preis: weniger Speicher bedeutet mehr Aufwand für die Speicherbereinigung.
Swap hilft – aber nicht wogegen man denkt
Ich habe den Auslagerungsspeicher auf 5,9 GB erhöht, und das war die richtige Entscheidung. Aber nicht aus dem Grund, der oft genannt wird.
Swap macht einen zu kleinen Server nicht schnell. Was ausgelagert ist, ist langsam, und daran ändert kein Aufstocken etwas. Was Swap verhindert, ist etwas anderes und viel Wichtigeres: dass der Kernel bei einer Speicherspitze einen Prozess abschießt. Ohne Puffer trifft es bei einer solchen Spitze irgendeinen Dienst – oft nicht den schuldigen, sondern den größten. Dann steht plötzlich die Ticketverwaltung, weil ein Import zu viel Speicher wollte.
Mit ausreichend Swap wird es in solchen Momenten zäh statt tot. Zäh kann man beobachten und beheben; tot merkt man erst, wenn jemand fragt.
Bare metal statt Container – eine bewusste Entscheidung
Fast alles läuft bei mir direkt auf dem System, nicht in Containern. Der Grund ist schlicht Speicher: Jeder Container bringt seine eigenen Bibliotheken mit, und bei einem knappen Budget summiert sich das.
Der Preis dafür sind Abhängigkeiten, die sich in die Quere kommen. Auf dieser Maschine laufen zwei PHP-Versionen parallel, weil zwei Anwendungen unterschiedliche Anforderungen haben. Das funktioniert, ist aber genau die Sorte Detail, die man sechs Monate später vergessen hat und dann bei einem Update wiederentdeckt.
Wer den Speicher hat, sollte Container nehmen. Wer ihn nicht hat, sollte dokumentieren.
Die ehrliche Bilanz
Dieser Aufbau trägt meine eigene Nutzung problemlos. Er würde keine Kundenlast tragen, und er hat keine Redundanz – fällt die Maschine aus, ist alles weg, bis ich sie wiederherstelle.
Was ich daraus gelernt habe und was auch für größere Umgebungen gilt: Der Engpass liegt selten dort, wo man ihn vermutet. Ich hätte auf die Datenbanken getippt, auf den Minecraft-Server, auf die Vektordatenbank. Tatsächlich verbrauchen die zusammen weniger als ein Viertel dessen, was die Versionsverwaltung sich nimmt.
Deshalb: erst messen, dann optimieren. ps -eo rss,comm --sort=-rss | head dauert eine Sekunde und beendet jede Diskussion, die sonst auf Vermutungen beruht.