Odoo-Server dimensionieren: CPU, RAM, Worker
Kurz gesagt
Für eine eigene Installation gilt unter Linux die Faustregel der Odoo-Dokumentation 20.0 als Planungsrichtwert: rechnerisch zweimal die Prozessorkerne plus eins an Prozessen, ein Worker trägt rund sechs gleichzeitige Nutzer. Bei Odoo Online wählen Sie keine Hardware; bei Odoo.sh buchen Sie Worker und Speicher selbst und der Konfigurator nennt eigene Richtwerte. In Deutschland, Österreich und der Schweiz gelten dieselben Werte, weil sie am Hostingmodell hängen; entscheidend sind die gleichzeitigen Zugriffe in der Spitze, nicht die Zahl der Konten.
Das Wichtigste
- Faustregel der Dokumentation 20.0 als Planungsrichtwert für die eigene Installation: Prozessorkerne mal zwei plus eins an Prozessen; ein Worker trägt rund sechs gleichzeitige Nutzer.
- Je Worker: 150 MB für leichte, rund 1 GB für schwere Anfragen; die Seite setzt 80 zu 20 Prozent an.
- Für Odoo.sh empfiehlt der Konfigurator einen zusätzlichen Worker je 25 Backend-Benutzer und je 5.000 Frontend-Besucher pro Tag.
- Cron-Worker brauchen zusätzlich Prozessorleistung; als Vorgabe nennt die Referenz zwei Cron-Threads (max_cron_threads).
- PostgreSQL 18: shared_buffers ist mit 128 MB voreingestellt; als Startwert nennt die Dokumentation 25 Prozent des Arbeitsspeichers, auf einem eigenen Datenbankserver mit mindestens 1 GB RAM.
Zwei Betriebe mit je 40 Mitarbeitenden brauchen nicht dieselbe Maschine: Der eine bucht Belege und Rechnungen, der andere betreibt zusätzlich einen Webshop, versendet Serienmails und lässt jede Nacht Auswertungen laufen. Die Rechnung der Odoo-Dokumentation setzt deshalb bei gleichzeitigen Zugriffen, Prozessen und Arbeitsspeicher je Worker an.
Wer die Größe festlegt
Bei Odoo Online hostet und verwaltet Odoo die private Datenbank selbst; Kerne und Arbeitsspeicher sind nicht Teil Ihrer Wahl. Das Hosting ist im Tarif enthalten; die Preisseite nennt unbegrenzten Speicherplatz bis zu 100 GB, ab mehr als 100 GB kann Odoo nach der Acceptable Use Policy einen Umzug auf Odoo.sh vorschlagen.
Bei Odoo.sh buchen Sie zusätzliche Datenbank-Worker über Ihren Account Manager; die Dokumentation verlangt dafür ein Odoo-Enterprise-Abonnement, das das Odoo.sh-Hosting einschließt. Abgerechnet wird in Einheiten: je Worker 60,00 Euro im Monat, bei jährlicher Zahlung 48,00 Euro, je GB Speicher 0,20 Euro (0,16 Euro), Stand 14. Oktober 2026; es sind Anbieterpreise, die sich ändern können, und die Seite nennt keine Umsatzsteuerangabe. Mehr als 16 Worker und 512 GB Speicher lassen sich im Konfigurator nicht direkt einstellen. Für die Größe empfiehlt der Konfigurator einen zusätzlichen Worker je 25 Backend-Benutzer und je 5.000 Frontend-Besucher pro Tag sowie zu Beginn 1 GB Speicher je Benutzer.
Bei einer eigenen Installation (On-Premise) wählen Sie Prozessor, Arbeitsspeicher und alle Werte selbst. Dort ist der Multiprozess-Betrieb der Produktionsmodus; er wird über die Option workers eingeschaltet. Bleibt sie auf ihrem Standardwert 0, läuft der Multithreading-Server, den die Dokumentation für Entwicklung und Demonstrationen nennt und der wegen der Python-Beschränkung (GIL) die Hardware nicht ausnutzt. Den Multiprozess-Betrieb nennt die Dokumentation nur für Linux und andere Unix-Systeme; unter Windows ist er nicht verfügbar.
Worauf es ankommt
Fünf Stellschrauben greifen ineinander; jede Zeile nennt ihre Quelle.
| Stellschraube | Regel in der Dokumentation 20.0 | Wirkung |
|---|---|---|
| Prozessorkerne | Faustregel: Prozesse = Kerne × 2 + 1 | Planungsrichtwert für die Zahl der Prozesse samt Cron-Worker; keine technische Obergrenze |
| Gleichzeitige Nutzer | ein Worker trägt rund sechs gleichzeitige Nutzer | bestimmt die Zahl der HTTP-Worker |
| Art der Anfragen | 80 Prozent leicht zu 150 MB, 20 Prozent schwer zu rund 1 GB je Worker | bestimmt den Arbeitsspeicher |
| Cron-Aufträge | Cron-Worker brauchen zusätzlich Prozessorleistung | Hintergrundjobs; Vorgabe zwei Cron-Threads (max_cron_threads) |
| Livechat | eigener Worker auf dem gevent-Port, Vorgabe 8072 | ein zusätzlicher Prozess; Pfade unter /websocket/ müssen dorthin geleitet werden |
Dimensionierungstabelle nach Nutzerzahl
Die folgende Tabelle ist eine Beispielrechnung nach den beiden Faustregeln der Dokumentation, keine Zusage des Anbieters. Angenommen sind: gleichzeitige Nutzer in der Spitze sind ein Viertel der angemeldeten Backend-Benutzer, gerundet; ein Worker trägt sechs gleichzeitige Nutzer; dazu kommt ein Cron-Worker; Frontend-Besucher und der Livechat-Worker sind nicht eingerechnet. Je Worker rechnet die Tabelle mit rund 325 MB (0,8 × 150 MB + 0,2 × 1 GB). Die Kerne sind so gewählt, dass die Prozesszahl in die Faustregel passt. Die Tabelle gilt für die eigene Installation; die Richtwerte des Odoo.sh-Konfigurators (ein zusätzlicher Worker je 25 Backend-Benutzer und je 5.000 Frontend-Besucher pro Tag) sind eine eigene Bezugsgröße für das gehostete Angebot und werden mit dieser Tabelle nicht verrechnet.
| Angemeldete Benutzer | Gleichzeitige Nutzer (Annahme) | HTTP-Worker | Prozesse mit Cron-Worker | Prozessorkerne | Arbeitsspeicher für Odoo (GB) |
|---|---|---|---|---|---|
| 10 | 3 | 1 | 2 | 1 | 0,6 |
| 25 | 6 | 1 | 2 | 1 | 0,6 |
| 50 | 13 | 3 | 4 | 2 | 1,3 |
| 100 | 25 | 5 | 6 | 3 | 1,9 |
| 200 | 50 | 9 | 10 | 5 | 3,2 |
| 300 | 75 | 13 | 14 | 7 | 4,4 |
Die Spalte Arbeitsspeicher betrifft nur die Odoo-Prozesse. Für Odoo.sh nennt der Konfigurator zusätzlich einen Worker je 5.000 Frontend-Besucher pro Tag; für die eigene Installation ist die Zahl der gleichzeitigen Zugriffe maßgeblich.
So rechnet die Dokumentation selbst
Die Bereitstellungsseite führt ein eigenes Beispiel: 4 Prozessorkerne, 8 Threads und 60 gleichzeitige Benutzer. Aus 60 ÷ 6 folgt die theoretisch benötigte Zahl von 10 Workern, aus der Faustregel 4 × 2 + 1 die theoretische Maximalzahl von 9 Prozessen. Sie setzt deshalb 8 HTTP-Worker und einen Cron-Worker an und kommt auf 9 × (0,8 × 150 MB + 0,2 × 1.024 MB) ≈ 3 GB Arbeitsspeicher für Odoo. Zum Schluss empfiehlt die Seite, die CPU-Auslastung zu messen und zu prüfen, ob der Wert zwischen 7 und 7,5 liegt.
Die Grenzen je Prozess stehen im selben Beispiel in der Konfigurationsdatei: limit_memory_soft 600 MiB, limit_memory_hard 1.600 MiB, max_cron_threads 1 und workers 8. Der Prozess-Verwalter überwacht die Grenzen: Wird limit_memory_soft überschritten, beendet und ersetzt er den Worker am Ende der laufenden Anfrage; überschreitet ein Worker limit_memory_hard, beendet er ihn sofort, ohne das Ende der Anfrage abzuwarten. Die Optionsreferenz nennt als Vorgabe 2.048 MiB (weich) und 2.560 MiB (hart).
Was PostgreSQL zusätzlich braucht
Odoo hält eigene Verbindungen zur Datenbank; das Konfigurationsbeispiel der Bereitstellungsseite setzt dafür max_connections = 80. PostgreSQL nennt als Vorgabe typischerweise 100 Verbindungen und weist darauf hin, dass ein höherer Wert mehr Ressourcen belegt, darunter Shared Memory; bei System-V-Semaphoren belegt jede erlaubte Verbindung ein Semaphor. Setzen Sie die Obergrenze über die Zahl Ihrer Odoo-Prozesse, aber nicht beliebig hoch.
shared_buffers ist mit 128 MB voreingestellt; als angemessenen Startwert nennt die PostgreSQL-Dokumentation 25 Prozent des Arbeitsspeichers, ausdrücklich für einen eigenen Datenbankserver mit mindestens 1 GB RAM, und auf Systemen unter 1 GB einen kleineren Anteil. work_mem (Vorgabe 4 MB) gilt je Sortier- oder Hash-Operation, und mehrere Sitzungen können gleichzeitig rechnen, sodass der Verbrauch ein Vielfaches dieses Werts erreicht. effective_cache_size (Vorgabe 4 GB) reserviert dagegen keinen Speicher; er ist nur eine Annahme für den Abfrageplaner.
Typische Fehler
- Nach Konten statt nach Zugriffen rechnen. Die Dokumentation rechnet in gleichzeitigen Nutzern, nicht in angelegten Konten; wie viele davon in der Spitze gleichzeitig arbeiten, ist keine Anbietergabe, sondern eine Annahme, die Sie schätzen und später messen müssen.
- Multithreading im Produktivbetrieb lassen. Ohne gesetzte Option
workersläuft der Multithreading-Server, den die Dokumentation für Entwicklung und Demonstrationen nennt. - Speichergrenzen stehen lassen, ohne den Bedarf zu kennen. Überschreitet ein Worker
limit_memory_soft, wird er am Ende der laufenden Anfrage beendet und ersetzt; überschreitet erlimit_memory_hard, beendet der Prozess-Verwalter ihn sofort, und die laufende Anfrage bricht ab. Beide Grenzen gehören über den gemessenen Bedarf gelegt. - Nur Odoo rechnen. shared_buffers, work_mem je Sitzung und der Betriebssystem-Cache liegen außerhalb der Formel und brauchen eigenen Arbeitsspeicher.
- Mehr Worker als Rechenzeit. Odoo.sh hält ausdrücklich fest, dass zusätzliche Worker nur mehr gleichzeitige Verbindungen erlauben; langsame Vorgänge beheben sie nicht.
So gehen Sie vor
- Zählen Sie die gleichzeitigen Zugriffe in Ihrer Spitzenstunde, nicht die angelegten Konten. Backend, Portal und Website zählen Sie getrennt.
- Nehmen Sie die Zeile der Tabelle, die über Ihrer Zählung liegt, und runden Sie nach oben.
- Tragen Sie
workers,max_cron_threadsund die Speichergrenzen in die Konfigurationsdatei ein und richten Sie den Proxy so ein, dass Pfade unter /websocket/ am Livechat-Worker ankommen. - Messen Sie danach die Auslastung, wie es die Bereitstellungsseite empfiehlt; bleibt der Prozessor dauerhaft am Anschlag, hilft die Ursachensuche im Artikel Odoo ist langsam mehr als eine größere Maschine.
- Dimensionieren Sie PostgreSQL mit: Verbindungsplätze über der Zahl Ihrer Odoo-Prozesse und shared_buffers als Anteil des Arbeitsspeichers; die 25 Prozent nennt die PostgreSQL-Dokumentation für einen eigenen Datenbankserver mit mindestens 1 GB RAM.
- Planen Sie Speicherplatz ein: Datenbank, Dateiablage und Sicherungen wachsen mit; für Odoo.sh empfiehlt der Konfigurator zu Beginn 1 GB je Benutzer. Den Ablauf beschreibt Odoo sichern.