Why Worker Configuration Matters
Odoo uses a multi-process architecture: a master process manages multiple worker processes, each handling HTTP requests independently. Too few workers means requests queue during peak hours. Too many workers means memory exhaustion and OOM kills. Getting the balance right determines whether your Odoo instance handles 10 or 100 concurrent users reliably.
Worker Count Formula
# Basic formula
workers = (CPU_cores × 2) + 1
# Examples:
# 2 cores → 5 workers
# 4 cores → 9 workers
# 8 cores → 17 workers
# 16 cores → 33 workersReserve 1 worker for the cron thread (Odoo uses a dedicated cron worker).
Memory Allocation
# Each worker needs:
# - 150MB minimum (simple operations)
# - 300MB typical (average Odoo usage)
# - 500MB+ heavy (large reports, complex computed fields)
# Memory formula:
total_needed = workers × 300MB + 500MB (system + PostgreSQL)
# Examples:
# 5 workers: 5 × 300MB + 500MB = 2.0 GB minimum
# 9 workers: 9 × 300MB + 500MB = 3.2 GB minimum
# 17 workers: 17 × 300MB + 500MB = 5.6 GB minimumConfiguration Parameters
# /etc/odoo/odoo.conf
[options]
# Worker count
workers = 5
# Memory limits per worker
limit_memory_hard = 2684354560 # 2.5 GB — kill worker above this
limit_memory_soft = 2147483648 # 2.0 GB — recycle worker above this
# Time limits per request
limit_time_real = 120 # Total wall-clock time (seconds)
limit_time_cpu = 60 # CPU time limit (seconds)
# Request limit (recycle worker after N requests)
limit_request = 8192
# Longpolling (WebSocket) — dedicated gevent worker
longpolling_port = 8072
gevent_port = 8072Configuration by Server Size
| Server | Workers | memory_soft | memory_hard | time_real | Users |
|---|---|---|---|---|---|
| 2 CPU / 4GB | 3 | 1.5GB | 2.0GB | 120s | 1-15 |
| 4 CPU / 8GB | 5 | 2.0GB | 2.5GB | 120s | 15-40 |
| 8 CPU / 16GB | 9 | 2.0GB | 2.5GB | 120s | 40-100 |
| 16 CPU / 32GB | 17 | 2.0GB | 2.5GB | 180s | 100-300 |
| 32 CPU / 64GB | 33 | 2.5GB | 3.0GB | 300s | 300-500 |
Understanding Memory Limits
limit_memory_soft
When a worker exceeds this after completing a request, it is recycled (gracefully restarted). This prevents memory leaks from accumulating.
limit_memory_hard
If a worker exceeds this at any point, it is killed immediately. Set higher than soft to allow temporary spikes (large reports, heavy imports).
Common Mistake
Setting limit_memory_hard too low causes workers to be killed mid-request, resulting in 502 errors. Set it at least 500MB higher than the typical working set of your heaviest operations.
Longpolling Configuration
Odoo uses a dedicated gevent worker for WebSocket/longpolling (live chat, notifications, presence):
# Nginx configuration for longpolling
location /longpolling {
proxy_pass http://127.0.0.1:8072;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location / {
proxy_pass http://127.0.0.1:8069;
proxy_read_timeout 720s;
}Monitoring Worker Health
Signs of worker problems:
- Workers constantly recycling → memory_soft too low or memory leak
- Workers killed (502 errors) → memory_hard too low or heavy operations
- Request queuing → not enough workers for concurrent users
- High CPU idle → too many workers wasting resources
DeployMonkey Worker Management
DeployMonkey's AI agent monitors worker health and recommends configuration changes. It detects worker recycling, OOM kills, and request queuing — then provides specific configuration recommendations based on your server specs and actual usage patterns. Deploy on DeployMonkey for AI-optimized worker configuration on every plan.