Systemressourcen & Tuning

QuoteNode läuft als kleine Gruppe von Docker-Containern. Die Compose-Dateien werden mit Speicher- und CPU-Limits ausgeliefert, die für eine VM mit 4 GB RAM abgestimmt sind, 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 — eine großzügige CPU-Obergrenze kostet in Ruhe nichts und lässt einen Dienst Kerne nutzen, wenn er sie braucht. Ein cpus-Wert über der Kernanzahl des Hosts bedeutet einfach „alle verfügbaren Kerne nutzen”, daher sind die Standardwerte auf einer VM mit 1–2 Kernen sicher.

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

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

RAM anpassen

Jedes Limit ist eine optionale Umgebungsvariable. Setzen Sie sie in Ihrer .env.prod, um den Standard zu überschreiben:

# Beispiel: eine 8-GB-Maschine mit mehr gleichzeitiger Last
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

Belassen Sie die CPU-Standardwerte großzügig. 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.