How to Enable Odoo Multi-Processing Mode

Odoo multi-processing mode is activated by setting workers = N (where N is greater than 0) in odoo.conf. Once enabled, Odoo spawns N independent Python worker processes plus a separate gevent longpolling process on port 8072. Multi-processing is mandatory for production — threaded mode cannot safely serve multiple concurrent users.

Threaded Mode vs Multi-Processing Mode

Understanding the difference between the two modes is essential before changing any configuration.

Threaded Mode (workers = 0)

In threaded mode, a single Python process handles all HTTP requests using multiple threads. Because Python's Global Interpreter Lock (GIL) prevents true parallel CPU execution, only one thread runs Python code at any moment. This means:

• One slow CPU-bound request (e.g., generating a complex report) delays all other requests
• A crash or memory error in one request can corrupt shared state for other requests
• You cannot take advantage of multiple CPU cores for Odoo work
• Memory limits (limit_memory_*) have no effect — there is only one process

Threaded mode is acceptable for development, single-user testing, and very low-traffic internal tools. It is not suitable for production.

Multi-Processing Mode (workers > 0)

Each worker is a completely independent Python process with its own memory space. A crash or memory spike in one worker does not affect others. Workers run in true parallel across CPU cores. Memory limits are enforced per-worker, so runaway processes are automatically recycled. This is the required mode for any Odoo deployment with more than one active user.

When to Switch to Multi-Processing

• Any production deployment — always
• When more than 2–3 users are actively using the system simultaneously
• When you need live chat, Discuss notifications, or IoT module functionality
• When running scheduled actions that must not block user-facing requests
• When you want meaningful memory limit enforcement

Complete Multi-Processing Configuration

# /etc/odoo/odoo.conf

# ---- Core process settings ----
workers = 4                  # HTTP worker count; formula: (2 × vCPU) + 1
max_cron_threads = 1         # Background/cron worker count

# ---- Memory limits (bytes) ----
# Soft: worker recycles gracefully after current request if exceeded
limit_memory_soft = 671088640   # 640 MB

# Hard: worker killed immediately if exceeded (no graceful finish)
limit_memory_hard = 805306368   # 768 MB

# ---- Time limits (seconds) ----
limit_time_cpu  = 60         # CPU time per request
limit_time_real = 120        # Wall-clock time per request

# ---- Longpolling port ----
# Gevent worker starts automatically on this port when workers > 0
longpolling_port = 8072

# ---- Other recommended settings ----
proxy_mode = True            # Required when behind Nginx
db_maxconn = 64              # Max PostgreSQL connections per worker

Sizing Workers by Server

See the full sizing table in How to Configure Odoo Workers for Best Performance. As a quick reference:

• 2 GB RAM, 2 vCPU: workers = 3, max_cron_threads = 1
• 4 GB RAM, 2 vCPU: workers = 4, max_cron_threads = 1
• 8 GB RAM, 4 vCPU: workers = 8, max_cron_threads = 2

Applying the Configuration

# Edit odoo.conf
sudo nano /etc/odoo/odoo.conf

# Restart Odoo to apply
sudo systemctl restart odoo

# Verify workers started
ps aux | grep "[o]doo"
# You should see N worker processes + 1 gevent process

# Confirm longpolling port is listening
ss -tlnp | grep 8072

Configuring Nginx for Multi-Processing Mode

When workers > 0, the longpolling gevent process starts on port 8072. Your Nginx config must proxy /web/websocket (Odoo 16+) or /longpolling (Odoo 15 and older) to this port. Without this, Discuss and live chat will not function.

upstream odoo-longpolling {
server 127.0.0.1:8072;
}

# In your server block:
location /web/websocket {
proxy_pass         http://odoo-longpolling;
proxy_http_version 1.1;
proxy_set_header   Upgrade    $http_upgrade;
proxy_set_header   Connection "Upgrade";
proxy_read_timeout 86400s;
}

For the complete Nginx configuration including SSL, see How to Set Up Odoo Behind Nginx Reverse Proxy.

Verifying Multi-Processing Is Working

# Count running Odoo processes (should be workers + 1 gevent + 1 master)
ps aux | grep "[o]doo" | wc -l

# Check Odoo logs for worker startup messages
grep -i "worker\|gevent\|longpoll" /var/log/odoo/odoo.log | head -20

# Simulate concurrent load and watch workers
ab -n 100 -c 10 https://erp.example.com/web/login
# While running ab, watch worker CPU/memory
watch -n 1 'ps aux | grep "[o]doo" | grep -v grep'

Common Issues When Enabling Multi-Processing

How DeployMonkey Handles Multi-Processing

All DeployMonkey instances run in multi-processing mode by default. Worker counts, memory limits, and time limits are calculated from your plan's allocated resources at provisioning time. You never need to enable multi-processing manually — it is the baseline configuration on every plan including Free.

The platform's Nginx layer is pre-configured with the correct websocket proxy blocks for the specific Odoo version deployed on your instance. When you upgrade from Odoo 15 to Odoo 16+, DeployMonkey automatically updates the Nginx config from the old /longpolling path to the new /web/websocket path.

Worker health is monitored continuously. If a worker crashes repeatedly (indicating a persistent memory or code issue), the platform surfaces an alert in the dashboard and logs the crash reason, making it straightforward to identify a problematic custom module or runaway cron job.

Related Articles

• How to Configure Odoo Workers for Best Performance
• How to Set Up Odoo Behind Nginx Reverse Proxy
• How to Fix Odoo Out of Memory Error
• Odoo Slow? How to Diagnose and Fix Performance Issues

Frequently Asked Questions