Si vous ne retenez qu'une seule chose de ce post: plus de workers, c'est mieux, et la RAM détermine combien vous pouvez en avoir. Tout le reste n'est que détail.
Voici la version courte:
Prenez la RAM totale de votre serveur.
Soustrayez ce dont PostgreSQL a besoin (s'il fonctionne sur le même serveur) et ce dont le système d'exploitation a besoin.
Divisez ce qui reste par la RAM que vous autorisez par travailleur : 1 Go est un plafond sûr, 512 Mo fonctionne pour une utilisation légère.
C'est votre nombre de workers. Le reste de ce post explique pourquoi cela fonctionne, ce qu'est réellement un travailleur, et comment vérifier la cohérence du résultat par rapport à votre nombre d'utilisateurs.
Qu'est-ce qu'un Odoo worker?
Lorsque Odoo fonctionne en mode multi-processus (workers = N dans la configuration), il génère N processus de travail séparés. Chaque worker gère une requête HTTP à la fois. Un chargement de page dans Odoo n'est pas une seule requête: le client web envoie une série d'appels RPC, de demandes d'actifs et de connexions de long polling pour chaque écran que vos utilisateurs touchent.
Donc, le nombre de worker est, en pratique, votre plafond de demandes par seconde. Deux travailleurs signifient deux demandes traitées à tout instant ; tout le reste attend en ligne. Cette file d'attente est ce que les utilisateurs expérimentent comme "Odoo est lent aujourd'hui."
C'est pourquoi l'objectif est simple : exécuter autant de workers que votre machine peut en supporter.
La seule vraie limite est la RAM
Vous verrez parfois circuler une règle empirique basée sur le CPU
(travailleurs = cœurs × 2 + 1)
C'est un bon point de départ, mais sur de vrais serveurs Odoo la RAM s'épuise bien avant le CPU. Les workers passent la plupart de temps à attendre sur la base de données et sur les E/S, sans utiliser le CPU mais chacun occupe en permanence de la mémoire. Donc, dimensionnez la RAM, et laissez la règle du CPU être un critère de départage, pas la contrainte.
Étape 1 Calculez toite RAM disponible
Commencez à partir de la RAM totale de la machine et soustrayez tout ce qui n'est pas Odoo :
PostgreSQL, s'il fonctionne sur le même serveur. Une configuration courante réserve environ 25–40 % de la machine pour cela (shared_buffers plus mémoire de travail). Vérifiez ce que le vôtre utilise réellement.
Le système d'exploitation et tout ce qui fonctionne sur la machine (agents de surveillance, nginx, etc.). Prévoyez 1–2 Go.
ram_disponible = ram_totale − ram_postgres − ram_os
Si PostgreSQL vit sur son propre serveur, sautez cette soustraction, une des plusieurs bonnes raisons de les séparer à mesure que vous grandissez.
Étape 2 Décidez du budget RAM par worker
Chaque travailleur a besoin d'un plafond de mémoire (limit_memory_hard / limit_memory_soft dans la configuration). En pratique :
1 Go par worker est le défaut confortable. Presque toutes les charges de travail s'adaptent.
512 Mo par worker fonctionne si votre utilisation est légère : modules standards, pas de rapports lourds, pas de grosses importations/exportations. Vous obtenez deux fois plus de workers avec la même RAM, mais une seule requête lourde peut atteindre le plafond et être recyclée.
Si vous ne connaissez pas encore votre charge de travail, commencez à 1 Go. Vous pouvez la réduire plus tard une fois que vous avez observé l'utilisation réelle de la mémoire.
N'oubliez pas les travailleurs cron
workers = N ne compte que les travailleurs HTTP. Odoo démarre également des travailleurs cron, 2 par défaut (max_cron_threads), qui exécutent vos tâches planifiées : files d'attente de mail, actions automatisées, recompositions de stock. Ils consomment de la RAM exactement comme un travailleur HTTP, et une tâche planifiée lourde peut facilement utiliser le budget total par travailleur.
Alors réservez de la place pour eux avant de diviser. (Odoo exécute également un processus gevent/websocket pour les fonctionnalités en direct, petit, mais il provient du même pool.)
Étape 3 Diviser
workers = (available_ram − cron_workers × ram_per_worker) ÷ ram_per_worker
Exemple travaillé. Un serveur de 16 Go exécutant PostgreSQL localement :
Total RAM |
16 Go |
− PostgreSQL |
4 Go |
− OS et services |
2 Go |
Disponible pour Odoo |
10 Go |
− 2 travailleurs cron à 1 Go |
2 Go |
Resté pour les travailleurs HTTP |
8 Go |
Travailleurs HTTP à 1 Go each |
8 travailleurs |
Même machine, même coût, la seule décision est le budget par worker.
Vérification de la santé : travailleurs vs. nombre d'utilisateurs
Les conseils de dimensionnement d'Odoo suggèrent environ un worker par ~25 utilisateurs internes. Considérez cela comme un moyen d'estimer la machine dont vous avez besoin, pas comme un objectif a configurer.
Deux raisons pour lesquelles c'est seulement un guide approximatif :
La charge de travail varie énormément selon qui sont ces utilisateurs. Vingt-cinq personnes se connectant occasionnellement se comportent très différemment de vingt-cinq représentants commerciaux hammering le CRM toute la journée, ou d'une équipe d'entrepôt scannant des codes-barres toutes les quelques secondes.
Odoo est bavard. Chaque interaction utilisateur se divise en plusieurs requêtes. Des travailleurs supplémentaires absorbent ces pics, ce qui permet à l'interface de se sentir instantanée.
Alors utilisez le nombre d'utilisateurs pour choisir une taille de machine, puis remplissez cette machine avec autant de workers que sa RAM le permet. Si la formule vous donne 10 workers pour 50 utilisateurs, exécutez 10 workers, pas 2. Les travailleurs inactifs ne vous coûtent rien ; les travailleurs manquants vous coûtent du temps d'attente à chaque clic.
Référence rapide
ram_disponible = ram_totale − ram_postgres − ram_os
travailleurs = (RAM_disponible − worker_cron × ram_par_travailleur) ÷ ram_par_worker
ram_par_travailleur : 1 Go (sûr) ou 512 Mo (charges de travail légères)
travailleurs_cron : 2 par défaut (max_threads_cron), ils utilisent aussi de la RAM
taille de machine : ~1 travailleur par 25 utilisateurs internes, puis arrondir
principe : autant de travailleurs que la RAM le permet
Ou sautez l'arithmétique
Si vous préférez ne pas gérer les configurations des workers, les limites de mémoire et le réglage de PostgreSQL : chaque plan Skysize est livré avec une allocation fixe de travailleurs dimensionnée pour son niveau, 3 travailleurs sur Launch, 6 sur Scale, 12 sur Business, sur l'infrastructure que nous réglons et surveillons pour vous, pour à la fois Odoo Community et Enterprise.
Voir ce qui est inclus dans chaque plan.
Commencez d'un essai gratuit de 7 jours, pas de carte de crédit, et vos sauvegardes sont téléchargeables à tout moment, donc vous n'êtes jamais bloqué.