Gib deinen Server ein und du bekommst die odoo.conf für dein Live-System und jede Testkopie, dazu die postgresql.conf für die Datenbank, die sie sich teilen. Dahinter steckt dieselbe Rechnung, die calmo.cloud auf jedem verwalteten Server anwendet.
Was jeder Teil höchstens nehmen darf, nicht was er an einem ruhigen Nachmittag braucht. Sicher ist ein Plan nur, wenn die Zusagen aufgehen.
15,2 GB von 16 GB zugesagt. Alles passt.
17 Odoo-Prozesse · Odoo darf 90 der 110 Datenbankverbindungen öffnen, die PostgreSQL annimmt.
Ein Block pro Odoo. Speichergrenzen stehen in Bytes, so liest Odoo sie.
[options] workers = 9 max_cron_threads = 2 limit_memory_soft = 939524096 limit_memory_hard = 2147483648 limit_time_cpu = 600 limit_time_real = 1200 limit_request = 8192 db_maxconn = 6
9 Worker und 2 Cron-Threads · 896 MB weiche und 2 GB harte Grenze pro Prozess · 6 Datenbankverbindungen pro Prozess
[options] workers = 4 max_cron_threads = 2 limit_memory_soft = 536870912 limit_memory_hard = 2147483648 limit_time_cpu = 600 limit_time_real = 1200 limit_request = 8192 db_maxconn = 4
4 Worker und 2 Cron-Threads · 512 MB weiche und 2 GB harte Grenze pro Prozess · 4 Datenbankverbindungen pro Prozess
Ein PostgreSQL für alle. Trag die Zeilen in die postgresql.conf ein oder setz sie mit ALTER SYSTEM. shared_buffers, max_connections, max_worker_processes und autovacuum_max_workers greifen erst nach einem Neustart.
shared_buffers = '128MB' effective_cache_size = '8192MB' work_mem = '15MB' maintenance_work_mem = '512MB' max_connections = 125 max_worker_processes = 4 max_parallel_workers = 4 max_parallel_workers_per_gather = 1 max_parallel_maintenance_workers = 2 autovacuum_max_workers = 3 autovacuum_work_mem = '128MB' autovacuum_naptime = '30s' autovacuum_vacuum_scale_factor = 0.05 autovacuum_analyze_scale_factor = 0.02 autovacuum_vacuum_cost_limit = 1000 min_wal_size = '1024MB' max_wal_size = '4096MB' checkpoint_completion_target = 0.9 random_page_cost = 1.1 jit_above_cost = 500000 effective_io_concurrency = 200 default_statistics_target = 100 log_min_duration_statement = '1000ms' log_lock_waits = 'on' log_checkpoints = 'on' log_temp_files = '10MB'
PostgreSQL-Tuning nach Lehrbuch geht davon aus, dass die Datenbank den Server für sich allein hat. Odoos Deployment-Leitfaden geht davon aus, dass die Datenbank woanders läuft. Folgst du beiden auf einer Maschine, verteilen sie denselben Arbeitsspeicher zweimal.
| Für diesen Server | Lehrbuch + Odoo-Leitfaden | Dieser Rechner |
|---|---|---|
| PostgreSQL shared_buffers | 4 GB | 128 MB |
| PostgreSQL effective_cache_size | 12 GB | 8 GB |
| PostgreSQL work_mem | 20,1 MB | 15 MB |
| PostgreSQL max_connections | 200 | 125 |
| Odoo-Prozesse, alle Instanzen | 18 | 17 |
| Verbindungen, die Odoo öffnen darf | 1.152Odoo darf 1.152 Datenbankverbindungen öffnen, PostgreSQL nimmt aber nur 200 an. | 90 |
| Arbeitsspeicher für PostgreSQL und Odoo | 40 GBmehr, als der Server hatOdoos Leitfaden schätzt 9,7 GB | 13,6 GB |
PostgreSQL nach Lehrbuch für eine Webanwendung auf Linux mit SSDs: ein Viertel des Arbeitsspeichers für shared_buffers, drei Viertel für effective_cache_size, 200 Verbindungen. Odoos Regel von (Kerne × 2) + 1 Prozessen für jede Instanz, und was sie offenlässt, mit Odoos Standardwerten: 2 GB weiche Speichergrenze und 64 Verbindungen pro Prozess. Die Schätzung des Leitfadens rechnet ein Fünftel der Anfragen als schwer mit 1 GB, den Rest mit 150 MB.
Quellen: Odoos Deployment-Leitfaden und OdooBench. Die Werte sind ein Startpunkt für eine typische Odoo-Last; behalte deinen Server nach dem Einspielen im Blick.
Tuning nach Lehrbuch gibt PostgreSQL ein Viertel des Arbeitsspeichers. Neben Odoo fehlt dieser Speicher dem Seitencache des Betriebssystems, der dieselben Tabellen schon zwischenspeichert. Einen großen eigenen Cache bekommt PostgreSQL erst, wenn die Datenbanken in das passen, was übrig ist.
Odoos Regel legt ein System auf die ganze Maschine aus. Eine Testkopie bekommt stattdessen einen Anteil am Server und kann deinem Live-System so keinen Platz wegnehmen.
Jeder Odoo-Prozess darf standardmäßig 64 Verbindungen öffnen. Das Limit wird auf alle Prozesse des Servers verteilt, 15 bleiben frei für Backups, Monitoring und dich.
Jeder Worker bekommt im Alltag einen kleinen Anteil, aber die harte Grenze lässt Platz, damit ein großer Export oder Bericht fertig wird. Sie ist auf den halben Arbeitsspeicher gedeckelt, damit ein einzelner Ausreißer nicht den Server mitnimmt.
Auf calmo.cloud kopiert niemand diese Zahlen von Hand. Die Plattform liest die Hardware über ihren Monitoring-Agenten, stellt Odoo und PostgreSQL gemeinsam ein und sagt dir Bescheid, wenn ein neuer Dienst oder ein größerer Server neue Werte braucht. Die Regeln hinter diesem Rechner haben wir auf echten Servern geprüft, bevor sie eingebaut wurden.
mehr Anfragen pro Sekunde auf demselben Server mit 4 Kernen und 8 GB: 140 ohne Tuning, 273 mit
Wartezeit pro Klick im Alltag, von 55 auf 28 Millisekunden
der Durchsatz auf einem Server mit 16 Kernen und 84,5 Millionen Datensätzen: 59,9 Anfragen pro Sekunde ohne Tuning, 508,2 mit eingestelltem Odoo und eingestellter Datenbank
Auf einem Server mit 8 GB und 35 GB Daten kostete ein 2 GB großer Puffer 14 % Durchsatz gegenüber dem PostgreSQL-Standard, weil er den Cache des Betriebssystems verdrängt hat.
PostgreSQLs Query-Compiler sprang bei kurzen Abfragen auf großen Odoo-Tabellen an. Jetzt wartet er auf Abfragen, die wirklich teuer sind.
Eine harte Grenze von 1,25 × der weichen hat eine Gruppierung über zwei Millionen Werte abgebrochen. Mit 2 GB ist sie nach 8,3 Sekunden fertig.
Zahlen für 4 Kerne: Odoo 19 und PostgreSQL 18 mit 16,9 Millionen Datensätzen, acht angemeldete Nutzer, die dieselben Aufrufe wie der Web-Client senden, 60 Sekunden Aufwärmen und drei Läufe à 90 Sekunden pro Variante, Median der Läufe, keine Fehler. Die Zahlen für 16 Kerne stehen in der README von OdooBench.
OdooBench ist unser Open-Source-Benchmark für Odoo. Es meldet sich als echter Nutzer an, spielt ab, was der Web-Client beim Öffnen, Filtern oder Gruppieren einer Liste sendet, und sagt dir, ob eine Änderung wirklich etwas bewegt hat. Lass es vor und nach dem Einspielen dieser Werte laufen.
pip install git+https://github.com/havmedia/OdooBench odoobench run --url http://10.0.0.5:8069 --db production \ --login admin --scenario office-day --users 50 --out before.json odoobench compare before.json after.json
Ja, ohne Anmeldung. Die Zahlen kannst du auf jedem Server nutzen, mit oder ohne calmo.cloud.
Weil ein großer PostgreSQL-Cache auf einem Server, auf dem auch Odoo läuft, dem Cache des Betriebssystems Speicher wegnimmt, und der erledigt dieselbe Arbeit. Mit einem Puffer in der üblichen Lehrbuchgröße haben wir 14 % weniger Durchsatz gemessen. PostgreSQL bekommt einen größeren Cache, sobald deine Datenbanken in den übrigen Arbeitsspeicher passen.
Eine Testkopie ist zum Ausprobieren da, nicht für dein ganzes Team. Sie bekommt einen Anteil am Server, damit das Live-System auch mit mehreren Kopien daneben genug Platz behält.
Nein. Die Zahlen werden nur für die Berechnung dieser Seite verwendet.
Du gibst nichts ein. Die Plattform liest Kerne und Arbeitsspeicher vom Server, die Datenbankgröße aus PostgreSQL und rechnet neu, wenn du einen Dienst hinzufügst oder den Server vergrößerst. Sie startet die Datenbank nie hinter deinem Rücken neu, und wenn PostgreSQL einen Wert ablehnt, nimmt sie ihn von selbst zurück.
Trag dich auf die Warteliste ein für frühen Zugang und Neuigkeiten zum Start. Bring dein Odoo mit. Behalte deine Unabhängigkeit.
Wir nutzen datenschutzfreundliche Analyse, um zu sehen, wie die Website genutzt wird. Nichts wird gespeichert, bevor du dich entschieden hast.
Wähle, welche Kategorien du zulässt. Du kannst das jederzeit über die Fußzeile ändern.