Een traag Odoo is bijna altijd een van vier dingen: een aantal workers dat op de standaard is blijven staan, te weinig RAM voor die workers, een ontbrekende database-index, of custom code die bij elke load duur werk doet. Alle vier zijn te diagnosticeren, en de meeste zijn op te lossen zonder een grotere server te kopen.
Het is 9 uur 's ochtends, iedereen logt in, en Odoo kruipt. Een verkooporderlijst doet er tien seconden over om te openen. Een factuur opslaan blijft hangen. Tegen de middag is het weer prima, dus niemand kan het reproduceren, en het standaardantwoord wordt "de server is druk". Traagheid die komt en gaat is de ergste soort, want het voelt nooit urgent genoeg om te fixen en gaat ook nooit helemaal weg.
Dat Odoo traag is, is bijna nooit één groot ding. Het is meestal een sizing-instelling die op de standaard is blijven staan, een query zonder index erachter, of custom code die bij elke pagina-load iets duurs doet. Het goede nieuws is dat de gangbare oorzaken een korte lijst vormen, ze te diagnosticeren zijn, en de meeste op te lossen zijn zonder een grotere server te kopen. Hier is wat Odoo daadwerkelijk traag maakt, hoe je vindt welke jou raakt, en hoe een gezonde opzet eruitziet.
Waarom Odoo traag wordt
Odoo is een Python-applicatie die met een PostgreSQL-database praat. Wanneer een pagina traag is, gaat de tijd naar een van drie plekken: wachten op een vrije worker, wachten tot de database een query beantwoordt, of wachten tot Python-code klaar is. Bijna elk traagheidsverhaal is een van die drie, en de gebruikelijke boosdoeners zijn deze.
Te weinig workers, of het verkeerde aantal. Odoo handelt gelijktijdige verzoeken af met worker-processen. Stel er te weinig in en verzoeken wachten op elkaar in de rij, en dat is precies waarom het om 9 uur 's ochtends vastloopt wanneer iedereen binnenkomt. Veel installaties draaien de standaard van nul of één worker (single-process-modus) zonder het te beseffen, zodat het hele bedrijf één rijbaan deelt.
Te krap bemeten RAM, of de verkeerde geheugenlimieten. Elke worker heeft geheugen nodig, en PostgreSQL heeft zijn eigen geheugen nodig. Hou er één te kort en de server swapt naar schijf, wat honderden keren trager is dan RAM. Odoo herstart ook een worker die over zijn geheugenlimiet gaat, dus te laag ingestelde limieten veroorzaken constante herstarts, en te hoog ingestelde limieten laten één op hol geslagen verzoek de machine platleggen.
Ontbrekende database-indexen. PostgreSQL is snel als het direct naar de benodigde rijen kan springen en traag als het een hele tabel moet scannen. Een filter of sortering op een grote tabel zonder index erachter wordt trager naarmate de tabel groeit. Dit is de klassieke oorzaak van "vorig jaar ging het prima, nu is het traag".
Zware custom code. Een berekend veld dat voor elke rij in een lijst een query draait, een automatisering die bij elke opslag afgaat, een rapport dat duizenden records in het geheugen laadt. Custom logica geschreven zonder oog voor performance is de meest voorkomende reden dat één specifiek scherm traag is terwijl de rest van Odoo prima werkt.
Grote bijlagen in de database. Standaard kan Odoo geüploade bestanden in de database opslaan. Duizenden PDF's en afbeeldingen daarin laten de database opzwellen, vertragen back-ups en zorgen dat elke query een zwaardere tabel raakt. De oplossing is om de bestandsinhoud op het bestandssysteem te houden, niet in PostgreSQL.
Geen caching ervoor, of een traag netwerkpad. Statische bestanden (CSS, JavaScript, afbeeldingen) die Odoo direct serveert, geen reverse proxy, geen compressie, en een database die ver van de applicatieserver staat, voegen allemaal vertraging toe die niets met Odoo's eigen snelheid te maken heeft.
Hoe je diagnosticeert welke het is
Gok niet en koop niet eerst een grotere server. Vind de oorzaak en fix die. Werk het in deze volgorde af.
1. Houd de server in de gaten terwijl het traag is. Open een terminal tijdens het trage moment en kijk naar CPU, RAM en swap. Als RAM vol is en de server swapt, heb je je antwoord: voeg RAM toe of fix de geheugenlimieten. Als één CPU-core op 100% vastzit en de rest niets doet, draai je waarschijnlijk single-process of heb je te weinig workers. Als alles er rustig uitziet maar pagina's toch traag zijn, gaat de tijd naar de database of naar code, niet naar een volle server.
2. Controleer de worker-configuratie. Kijk naar de waarde van workers in je Odoo-config. Als die 0 is, zit je in single-process-modus en wordt elk verzoek serieel afgehandeld. Dit alleen al verklaart de meeste klachten van het type "traag zodra het team inlogt".
3. Zet slow query logging aan in PostgreSQL. Stel log_min_duration_statement in om elke query boven een drempel te loggen (zeg 1000 ms). Binnen een dag heb je een lijst met precies de queries die traag zijn, en die wijzen je direct naar de ontbrekende index of het dure stuk code. Dit is de meest nuttige diagnosestap die er is, en bijna niemand doet het.
4. Vind het trage scherm en lees dan de code. Als één specifieke pagina traag is, zet dan de developer-modus van Odoo aan en bekijk de query-teller en timing die hij rapporteert. Een lijstweergave die duizenden queries afvuurt om één pagina te renderen, is een berekend veld of een gerelateerd veld dat per rij werk doet. Nu weet je waar je moet kijken.
5. Controleer waar bijlagen staan. Een database die voor een bedrijf zonder zoveel echte data is uitgegroeid tot tientallen gigabytes, heeft zijn bestanden meestal in de database opgeslagen. Bevestig waar bijlagen worden opgeslagen voordat je de queries de schuld geeft.
De fixes, op volgorde van opbrengst
Stel het aantal workers correct in.
De startformule is (CPU-cores × 2) + 1, plus één extra voor de cron (geplande taken). Een server met 4 cores draait dus ongeveer 9 HTTP-workers en 1 cron-worker. Dit geeft elk verzoek een vrije rijbaan in plaats van een rij. Als je op workers = 0 zit, is deze ene verandering vaak de grootste snelheidssprong die je krijgt.
Bemeet RAM en de geheugenlimieten zodat ze matchen.
Reken op grofweg 1 GB of meer RAM per worker, plus geheugen voor PostgreSQL en het besturingssysteem. Stel limit_memory_soft zo in dat een worker die eroverheen gaat zijn huidige verzoek afmaakt en dan netjes herstart, en stel limit_memory_hard iets hoger in als het harde plafond, vaak de soft-limiet op ongeveer 70 tot 80 procent van de hard-limiet. Goed bemeten wordt een lekkend verzoek gerecycled zonder de server plat te leggen, en swap je nooit.
Voeg de ontbrekende indexen toe.
Neem de trage queries uit je PostgreSQL-log en voeg een index toe op de kolommen waarop wordt gefilterd of gesorteerd. Op een grote tabel kan dit een query van tien seconden tot een paar milliseconden terugbrengen. In Odoo kun je een veld ook als indexed markeren op het model, wat de nette manier is voor velden waarop je voortdurend filtert.
Fix de zware custom code.
Herschrijf het berekende veld zodat het in batch werkt in plaats van één query per rij, haal werk uit "bij elke opslag"-automatiseringen, en stop rapporten met alles in één keer in het geheugen te laden. Dit is developer-werk, maar het richt zich op precies het scherm dat je diagnose aanwees, dus de inspanning is klein en de opbrengst is direct.
Verplaats bijlagen naar het bestandssysteem.
Configureer Odoo om bijlage-inhoud op schijf op te slaan in plaats van in de database (de instelling ir_attachment.location). De database krimpt, back-ups versnellen, en elke query stopt met het meeslepen van het gewicht van je bestanden.
Zet een reverse proxy en caching ervoor.
Serveer statische bestanden via Nginx, zet gzip-compressie aan, en houd de database dicht bij de applicatieserver (zelfde datacenter, lage latency). Niets hiervan verandert Odoo, het stopt alleen met er vertraging omheen toe te voegen.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Een grotere server lost geen ontbrekende index op. Als de traagheid één niet-geïndexeerde query is, koop je met verdubbelde CPU een iets snellere scan van de hele tabel, en volgend jaar is het weer traag. Diagnosticeer eerst, schaal alleen op als de diagnose zegt dat de machine echt vol zit.
Meer workers is niet altijd beter. Elke worker vreet RAM, dus workers toevoegen op een server die al krap in het geheugen zit, laat hem swappen, wat alles trager maakt. Workers en RAM moeten samen bemeten worden, niet één voor één.
De vertraging om 9 uur 's ochtends en het "één scherm is traag"-probleem zijn verschillende bugs. De eerste is sizing (workers en RAM). De tweede is bijna altijd code of een ontbrekende index. Ze als hetzelfde behandelen is waarom mensen hardware tegen een softwareprobleem aangooien en geen verbetering zien.
"Het is traag" zonder meting is geen diagnose. De slow query log en de query-teller in developer-modus maken van "Odoo is traag" een "deze specifieke query op deze tabel duurt negen seconden". De eerste zin kun je niet oplossen. De tweede los je in een middag op.
Odoo Online (de SaaS) verbergt het meeste hiervan voor je: Odoo beheert de workers, RAM en database. Deze fixes gelden wanneer je Odoo zelf draait of met een partner, op Odoo.sh of je eigen server, waar de configuratie aan jou is om goed te krijgen. Eén kostennoot uit de praktijk: op Odoo.sh schaal je op door workers toe te voegen, en dat wordt snel duur, vooral voor een e-commerce site waar zwaar bezoekersverkeer een constante stroom verzoeken betekent, en meer verkeer steeds om meer workers blijft vragen. Voorbij een bepaald verkeersniveau is managed hosting via een Odoo-partner die de hele stack tunet vaak de betere deal; veel van onze leden bieden precies dat.
Snelle checklist
- Je weet of je multi-process draait (workers ingesteld) of single-process (
workers = 0). - Het aantal workers volgt
(CPU-cores × 2) + 1, met een aparte cron-worker. - RAM dekt grofweg 1 GB of meer per worker plus PostgreSQL en het OS, en de server swapt nooit onder belasting.
limit_memory_softenlimit_memory_hardzijn zo ingesteld dat workers netjes recyclen in plaats van crashen of ongelimiteerd doorlopen.- Slow query logging in PostgreSQL staat aan, en de trage queries die opduiken hebben indexen.
- Bijlagen worden op het bestandssysteem opgeslagen, niet in de database.
- Statische bestanden lopen via een reverse proxy met compressie, en de database staat dicht bij de app-server.
FAQ
Waarom is mijn Odoo 's ochtends traag maar 's middags prima?
Bijna altijd te weinig workers. Odoo handelt gelijktijdige verzoeken af met worker-processen, en als je single-process-modus draait (workers = 0) of te weinig workers, staat iedereen die om 9 uur 's ochtends inlogt achter elkaar in de rij. Tegen de middag daalt de belasting en voelt het prima. Zet het aantal workers op (CPU-cores x 2) + 1 plus een cron-worker, en zorg dat RAM ze dekt.
Hoeveel workers zou Odoo moeten hebben?
De startformule is (CPU-cores x 2) + 1 HTTP-workers, plus één extra worker voor geplande taken (cron). Een server met 4 cores draait ongeveer 9 HTTP-workers en 1 cron-worker. Bemeet dan RAM erbij: reken op grofweg 1 GB of meer per worker, plus geheugen voor PostgreSQL en het besturingssysteem, zodat de server nooit naar schijf hoeft te swappen.
Waarom laadt één scherm in Odoo traag terwijl de rest snel is?
Dat wijst op een ontbrekende database-index of zware custom code op dat scherm, niet op server-sizing. Een lijst of rapport dat duizenden queries afvuurt om één pagina te renderen, heeft meestal een berekend of gerelateerd veld dat per rij werk doet. Zet developer-modus aan om de query-teller te zien, zet slow query logging in PostgreSQL aan om de exacte query te vinden, en voeg dan de index toe of herschrijf de code in batch.
Maakt een grotere server Odoo sneller?
Alleen als de echte oorzaak is dat de server daadwerkelijk vol zit (RAM dat swapt, alle CPU-cores vastgezet). Als de traagheid een ontbrekende index of dure custom code is, helpt een grotere server nauwelijks en keert het probleem terug naarmate je data groeit. Diagnosticeer eerst: houd de server in de gaten tijdens het trage moment, controleer het aantal workers, en lees de slow query log. Schaal de hardware alleen op wanneer de diagnose zegt dat de machine de limiet is.
Moeten bijlagen in de Odoo-database worden opgeslagen?
Nee. Sla bijlage-inhoud op het bestandssysteem op, niet in PostgreSQL (de instelling ir_attachment.location). Bestanden in de database laten hem opzwellen, vertragen elke back-up, en laten queries extra gewicht meeslepen. Bestanden op schijf houden de database slank en snel.