De combien de workers Odoo a-t-il réellement besoin ?

Cœurs CPU x 2 + 1 donne le plafond, mais c'est la charge qui détermine le bon chiffre en pratique, puisqu'un worker gère environ 6 utilisateurs simultanés. Sur un serveur 4 cœurs avec 30 utilisateurs simultanés, 5 workers plus un thread cron tournent confortablement, à condition que la RAM suive.

Pourquoi workers = 0 est-il la valeur par défaut du profil développement ?

Régler workers = 0 fait tourner Odoo en mode threadé : un seul processus, un débogage plus simple et des options --dev qui fonctionnent. Cela ne permet toutefois pas d'exploiter plusieurs cœurs, donc ce mode ne doit jamais être exposé à de vrais utilisateurs.

Qu'est-ce qui distingue limit_memory_soft de limit_memory_hard ?

La limite souple attend qu'un worker termine sa requête en cours avant de le recycler proprement. La limite dure, elle, n'attend pas : elle tue le worker immédiatement, même en pleine requête. Considérez la limite dure comme le filet de sécurité, tandis que la souple s'occupe de l'hygiène mémoire au quotidien.

Que fait vraiment proxy_mode, et quand faut-il l'activer ?

Avec proxy_mode = True, Odoo fait confiance aux en-têtes X-Forwarded-* envoyés par votre reverse proxy, ce qui lui permet de voir correctement les vraies IP clientes et le schéma HTTPS. Activez-le uniquement quand nginx, Apache ou Traefik se trouve devant Odoo, et laissez-le désactivé sinon.

Pourquoi ma config affiche longpolling_port au lieu de gevent_port ?

C'est le même port sous un nouveau nom. Quand le worker live-chat/bus est passé à gevent dans Odoo 16, longpolling_port est devenu gevent_port. Le tuner choisit la bonne clé selon la version sélectionnée, et les deux utilisent 8072 par défaut de toute façon.

Est-ce un substitut aux tests de charge ?

Non, pas à lui seul. Il vous donne le même point de départ qu'un ingénieur Odoo expérimenté noterait avant de commencer à mesurer. À partir de là, validez sous un trafic proche de la production et laissez les métriques réelles guider vos workers et vos limites.

Outil gratuit · Tuner odoo.conf

Tuner odoo.conf

Indiquez les caractéristiques de votre serveur, et vous obtenez en retour un odoo.conf prêt pour la production : workers, threads cron, limites de mémoire et de temps, réglages proxy et base de données compris. Chaque valeur découle des recommandations officielles de déploiement d'Odoo. Aucune inscription, aucune adresse e-mail demandée.

Version Odoo

Profil de déploiement

Cœurs CPU

RAM totale

Utilisateurs simultanés attendus

Ce chiffre compte les personnes actives au même moment, pas le nombre total de comptes créés. Pour une entreprise de 100 employés, ce pic se situe généralement entre 20 et 40.Derrière un reverse proxy (nginx, Apache, Traefik) Cette option active proxy_mode afin qu'Odoo fasse confiance aux en-têtes X-Forwarded envoyés en amont. Elle devient nécessaire dès que le HTTPS se termine au niveau du proxy plutôt que sur Odoo lui-même.PostgreSQL tourne sur le même serveur Cette option réserve 25 % de la RAM pour la base de données et ajuste db_maxconn en fonction du pool de workers.

Valeurs calculées

Workers HTTP5

Threads cron1

Limite mémoire (souple, par worker)1015 MB

Limite mémoire (dure, par worker)1268 MB

Utilisation estimée / RAM disponible1.9 GB / 7 GB

odoo.conf

# odoo.conf generated by the Octura odoo.conf tuner
# https://octurasolutions.com/tools/odoo-conf-tuner
# Odoo 18 | production | 4 CPU cores | 8 GB RAM
# ~25 concurrent users | reverse proxy: yes | PostgreSQL on same host: no

[options]

# ---- Workers ----
workers = 5
# Odoo defaults to 2 cron threads; sized here against the CPU budget.
max_cron_threads = 1
# Recycle cron workers after N seconds (0 disables, Odoo 18+).
limit_time_worker_cron = 0

# ---- Memory limits (per worker, bytes) ----
limit_memory_soft = 1064304640
limit_memory_hard = 1329594368
# The gevent (websocket/longpolling) worker follows the limits above
# by default. Give it its own budget if live chat sessions pile up:
# limit_memory_soft_gevent = 1064304640
# limit_memory_hard_gevent = 1329594368

# ---- Time limits (seconds) ----
limit_time_cpu = 60
limit_time_real = 120
# Cron jobs follow limit_time_real by default (-1); raise it instead
# of the global limit if long batch jobs get killed (0 = no limit).
limit_time_real_cron = -1
limit_request = 65536

# ---- HTTP / proxy ----
# Behind a proxy, bind to loopback so Odoo is not reachable directly.
http_interface = 127.0.0.1
http_port = 8069
gevent_port = 8072
proxy_mode = True
# Let the web server deliver large files (needs matching nginx
# X-Accel-Redirect / apache X-Sendfile config before enabling):
# x_sendfile = True

# ---- Database ----
db_maxconn = 64
# The gevent worker shares db_maxconn by default; cap it separately
# if PostgreSQL connections are tight:
# db_maxconn_gevent = 8
# Point these at your PostgreSQL server:
# db_host = db.internal.example.com
# db_port = 5432
# db_sslmode = require
# db_user = odoo
# db_password = CHANGE-ME

# ---- Logging ----
log_level = info
# logfile = /var/log/odoo/odoo.log   (unset = stdout, fine under systemd/docker)

# ---- Security ----
list_db = False
# Only serve your production database (regex on the db name):
# dbfilter = ^mydb$
# Set a strong master password before going live:
# admin_passwd = CHANGE-ME

# ---- Misc ----
# Hours before transient (wizard) records are vacuumed; default 1.0.
transient_age_limit = 1.0
# data_dir = /var/lib/odoo
# addons_path = /opt/odoo/addons,/opt/odoo/custom-addons

Obtenir une revue serveur gratuite

Voyez ceci comme un point de départ plutôt qu'un remplacement des tests de charge : validez sous trafic réel, puis ajustez en conséquence.

Validé sur de vraies migrations

Des chiffres comme les vôtres, validés sur de vraies migrations

Voici trois engagements où la projection s'est vraiment transformée en réalité opérationnelle sur Odoo, et les études de cas complètes se trouvent sur la page service Migration.

ManufacturingV12 → V17
Fabricant industriel, Texas
12modules personnalisés repris intégralement, zéro perte
DistributionV14 → V18
Distributeur en gros, Québec
30%pages plus rapides une fois la mise à niveau livrée
Services professionnelsCE → Enterprise
Cabinet de conseil, Bruxelles
0hinterruption de production lors de la bascule

Les nombres d'implantations, de migrations et d'audits couvrent l'ensemble de la carrière de nos consultants seniors, y compris les projets livrés avant la fondation d'Octura en 2024. Les semaines avant go-live et la rétention sont mesurées sur les mandats d'Octura.

Comment le tuner calcule votre odoo.conf

Chaque chiffre ci-dessous suit les recommandations officielles de déploiement d'Odoo, les mêmes règles que nos ingénieurs utilisent sur les serveurs clients, appliquées directement aux specs que vous avez saisies :

Workers : cœurs x 2 + 1 fixe le plafond CPU, et chaque worker gère environ 6 utilisateurs simultanés. En partant de la demande utilisateur attendue, le tuner plafonne ce chiffre au maximum CPU moins les threads cron, sans jamais descendre sous 2 workers pour un déploiement en production.
Mémoire : un worker consomme en moyenne environ 325 Mo, entre 80 % de requêtes légères autour de 150 Mo et 20 % de requêtes lourdes proches de 1 Go. Une fois 1 Go réservé à l'OS, plus 25 % pour PostgreSQL s'il partage l'hôte, le pool se réduit jusqu'à ce que tout tienne. limit_memory_soft répartit ensuite 85 % de la RAM disponible entre les processus, et la limite dure se situe 25 % au-dessus.
Limites et sécurité : la production tourne avec des limites de temps strictes (60 s CPU / 120 s réel), list_db désactivé, et un rappel pour définir le mot de passe maître. Staging et développement, eux, reçoivent des limites relâchées afin de ne pas gêner les imports longs ni le débogage.

Notez que le tuner ne couvre que le côté Odoo. Pour les réglages PostgreSQL comme shared_buffers, work_mem et max_connections, essayez pgtune

Comment ce calcul est effectué

L'optimiseur de workers et de mémoire Odoo d'Octura part de la formule de dimensionnement standard, workers = cœurs CPU × 2 + 1, puis retranche les threads cron réservés par votre déploiement et plafonne selon la RAM réellement disponible, en comptant environ 325 Mo par worker. Il renvoie le nombre de workers d'odoo.conf et les limites mémoire dures et souples adaptées à votre serveur.

Questions fréquentes sur le réglage d'odoo.conf

De combien de workers Odoo a-t-il réellement besoin ?
Cœurs CPU x 2 + 1 donne le plafond, mais c'est la charge qui détermine le bon chiffre en pratique, puisqu'un worker gère environ 6 utilisateurs simultanés. Sur un serveur 4 cœurs avec 30 utilisateurs simultanés, 5 workers plus un thread cron tournent confortablement, à condition que la RAM suive.
Pourquoi workers = 0 est-il la valeur par défaut du profil développement ?
Régler workers = 0 fait tourner Odoo en mode threadé : un seul processus, un débogage plus simple et des options --dev qui fonctionnent. Cela ne permet toutefois pas d'exploiter plusieurs cœurs, donc ce mode ne doit jamais être exposé à de vrais utilisateurs.
Qu'est-ce qui distingue limit_memory_soft de limit_memory_hard ?
La limite souple attend qu'un worker termine sa requête en cours avant de le recycler proprement. La limite dure, elle, n'attend pas : elle tue le worker immédiatement, même en pleine requête. Considérez la limite dure comme le filet de sécurité, tandis que la souple s'occupe de l'hygiène mémoire au quotidien.
Que fait vraiment proxy_mode, et quand faut-il l'activer ?
Avec proxy_mode = True, Odoo fait confiance aux en-têtes X-Forwarded-* envoyés par votre reverse proxy, ce qui lui permet de voir correctement les vraies IP clientes et le schéma HTTPS. Activez-le uniquement quand nginx, Apache ou Traefik se trouve devant Odoo, et laissez-le désactivé sinon.
Pourquoi ma config affiche longpolling_port au lieu de gevent_port ?
C'est le même port sous un nouveau nom. Quand le worker live-chat/bus est passé à gevent dans Odoo 16, longpolling_port est devenu gevent_port. Le tuner choisit la bonne clé selon la version sélectionnée, et les deux utilisent 8072 par défaut de toute façon.
Est-ce un substitut aux tests de charge ?
Non, pas à lui seul. Il vous donne le même point de départ qu'un ingénieur Odoo expérimenté noterait avant de commencer à mesurer. À partir de là, validez sous un trafic proche de la production et laissez les métriques réelles guider vos workers et vos limites.