Systemressourcen & Tuning

QuoteNode läuft als kleine Gruppe von Docker-Containern. Die Compose-Dateien werden mit Speicherlimits ausgeliefert, die für eine VM mit 4 GB RAM abgestimmt sind, ohne standardmäßige CPU-Begrenzung, und jedes Limit lässt sich über eine Umgebungsvariable überschreiben, sodass Sie den Stack passend für Ihre Maschine dimensionieren können.

Minimum und Empfehlung

Stufe	Host-RAM	Host-CPU	Hinweise
Minimum	4 GB	2 Kerne	Standardprofil. Komfortabel für ein kleines Team (≈10 Benutzer / ≈1 000 Produkte).
Empfohlen	8 GB	4 Kerne	Spielraum für gleichzeitige Importe/Exporte und PDF-Spitzen.
Ausgelastet	8–16 GB	4–8 Kerne	≈100 Benutzer / ≈20 000 Produkte mit parallelen Massenoperationen.

Der Stack ist im Leerlauf genügsam: in Ruhe verbraucht der gesamte Stack etwa 1,5 GiB RAM, unabhängig davon, wie viele Daten in der Datenbank liegen (es gibt keinen Entity-Cache in der JVM — die Daten liegen in PostgreSQL). RAM skaliert mit der Parallelität von Massenoperationen (Import/Export/PDF), nicht mit der Anzahl der Benutzer oder Datensätze.

Wie Container-Limits funktionieren

mem_limit ist eine harte Obergrenze, keine Reservierung. Ein Container nutzt nur, was er tatsächlich anfasst, bis zum Limit; ein Container, der sein Limit überschreitet, wird per OOM beendet. Ein höheres Limit kostet keinen Speicher — es hebt nur die Sicherheitsgrenze an.

Das Standardprofil summiert sich auf etwa 3 520 MiB an Obergrenzen, was auf einen 4-GB-Host passt und ~575 MiB für das Betriebssystem übrig lässt. Da die reale Leerlaufnutzung weit niedriger ist (~1,5 GiB), sind die Obergrenzen Spielraum für Lastspitzen, nicht der erwartete Verbrauch.

cpus ist ebenfalls eine Obergrenze, aber CPU ist im Leerlauf kostenlos, daher ist standardmäßig keine CPU-Obergrenze gesetzt: Jeder Dienst darf alle Kerne des Hosts nutzen, und ungenutzte CPU kostet nichts. Wenn Sie eine *_CPUS-Obergrenze setzen, bleiben Sie bei oder unter der Kernanzahl des Hosts — Docker verweigert den Start eines Containers, dessen cpus die verfügbaren Kerne übersteigt.

Standard-Limits pro Dienst (4-GB-Profil)

Dienst	Speicher	CPU	Rolle
backend	1536m	alle Kerne	API-/Web-Server (JVM-Heap skaliert automatisch auf 70 % davon)
postgres	512m	alle Kerne	Datenbank
backup-worker	832m	alle Kerne	Geplante Backups (pg_dump)
gotenberg	448m	alle Kerne	Chromium-PDF-Rendering
frontend	96m	alle Kerne	Caddy, das den statischen Build ausliefert
caddy	96m	alle Kerne	TLS-/Reverse-Proxy-Ingress — CADDY_MEM_LIMIT bei starkem TLS-Verkehr erhöhen

RAM anpassen

Jedes Limit ist eine optionale Umgebungsvariable. Setzen Sie sie dort, wo Ihre Installation ihre Einstellungen hält:

• Release-Paket (Server, LAN, Laptop oder ein NAS-Ordner): die Datei .env neben docker-compose.yml; führen Sie danach docker compose up -d aus, das die geänderten Container neu erstellt.
• Portainer: die Umgebungsvariablen des Stacks (stack.env); aktualisieren Sie danach den Stack.
• Coolify: Dessen Compose-Datei setzt keine Limits pro Dienst, daher haben diese Variablen dort keine Wirkung.

# Example: an 8 GB machine with more concurrent load
BACKEND_MEM_LIMIT=3g
POSTGRES_MEM_LIMIT=1g
GOTENBERG_MEM_LIMIT=768m

Der Java-Heap des Backends skaliert automatisch auf 70 % von BACKEND_MEM_LIMIT (über MaxRAMPercentage), sodass ein höheres Limit den Heap automatisch erhöht — keine JVM-Flags zu bearbeiten. Dasselbe gilt proportional für den backup-worker (der 45 % nutzt).

Verfügbare Variablen: BACKEND_MEM_LIMIT, BACKEND_CPUS, POSTGRES_MEM_LIMIT, POSTGRES_CPUS, WORKER_MEM_LIMIT, WORKER_CPUS, GOTENBERG_MEM_LIMIT, GOTENBERG_CPUS, FRONTEND_MEM_LIMIT, FRONTEND_CPUS, CADDY_MEM_LIMIT, CADDY_CPUS.

CPU

Begrenzen Sie die CPU nur, wenn eine andere Last auf dem Host geschützt werden muss. Der einzige Punkt, an dem CPU in der Praxis zählt, ist der Kaltstart: das JVM-basierte Backend und der Worker booten einen großen Anwendungskontext, was CPU-gebunden ist. Auf einem einzelnen Kern kann ein Kaltstart Minuten dauern; mit 2+ Kernen liegt er deutlich unter einer Minute. Die Healthcheck-Karenzzeit des Workers berücksichtigt langsame Starts bereits, sodass sich eine eingeschränkte Maschine von selbst erholt, ohne Restart-Schleife.

Out-of-Memory-Probleme vermeiden

• Verkleinern Sie WORKER_MEM_LIMIT nicht unter ~768m. Ein Backup-Lauf (pg_dump + tar + gzip + die JVM) erreicht eine Spitze von etwa 607 MiB; mit weniger Spielraum kann er mitten im Backup beendet werden.
• Auf einer 2-GB-VM ist das Standardprofil zu groß — senken Sie die Limits (z. B. BACKEND_MEM_LIMIT=768m, POSTGRES_MEM_LIMIT=384m), damit die Summe unter dem physischen RAM bleibt. Der Backend-Heap folgt dem Limit automatisch.
• Behalten Sie den Host im Blick, nicht nur die Container. Wenn auf dem Host andere Workloads laufen, zählen Sie deren Speicher mit — Docker erzwingt nur Obergrenzen pro Container, nicht die Gesamtnutzung des Hosts.
• Ein Container, der wiederholt mit Exit-Code 137 neu startet, deutet auf einen OOM-Kill hin; erhöhen Sie das *_MEM_LIMIT dieses Dienstes.