How to Fix Odoo Out of Memory Error

An Odoo out of memory (OOM) error occurs when the server's RAM is exhausted, causing the Linux kernel to kill Odoo worker processes. The most common culprits are too many worker processes configured relative to available RAM, limit_memory_hard set too high, large PDF report generation, or background cron jobs that leak memory over time.

Why Odoo Runs Out of Memory

Odoo runs in either threaded mode (single process, multiple threads) or multi-processing mode (multiple worker processes). In multi-processing mode each worker is a separate Python process that starts at roughly 150 MB and can grow to 300–600 MB depending on the modules installed and the complexity of the requests it handles.

The Linux OOM killer steps in when total memory — RAM plus swap — is exhausted. You will see entries like Out of memory: Kill process <pid> (python3) in /var/log/syslog or journalctl -k. Common scenarios that trigger this:

• More workers configured than RAM can support (e.g., 8 workers on a 2 GB VPS)
• limit_memory_hard set to a value larger than physical RAM, so workers are never recycled
• Generating large PDF reports (invoices, stock moves) that inflate a worker's RSS dramatically
• Cron jobs that process thousands of records in a single transaction without releasing memory
• Custom modules with memory leaks — unbounded caches, large attachment reads into RAM

Step-by-Step Fix

1. Check Current Memory Usage

Before touching any config file, get a baseline reading of how memory is actually being consumed.

# Overall RAM picture
free -h

# Per-process breakdown — sort by RSS
ps aux --sort=-%mem | head -20

# Interactive view — press M to sort by memory
htop

# Confirm OOM kills in kernel log
dmesg | grep -i "oom\|killed process"
sudo journalctl -k | grep -i oom

2. Tune Worker Count

The recommended formula is workers = (2 × CPU cores) + 1, but you must also verify you have enough RAM. Budget 300 MB per worker as a safe minimum.

# /etc/odoo/odoo.conf

# Example: 2 vCPU, 4 GB RAM — leave 1 GB for PostgreSQL and OS
workers = 4
max_cron_threads = 1

On a 2 GB VPS, use 2–3 workers maximum. On a 4 GB VPS, 4–5 workers is safe. See the full sizing table in How to Configure Odoo Workers for Best Performance.

3. Set Sensible Memory Limits

# /etc/odoo/odoo.conf

# Soft limit — worker recycles after a request if RSS exceeds this (bytes)
limit_memory_soft = 671088640   # 640 MB

# Hard limit — worker is killed immediately if RSS exceeds this
limit_memory_hard = 805306368   # 768 MB

# Time limits prevent runaway requests from hogging a worker
limit_time_cpu = 60
limit_time_real = 120

The key rule: limit_memory_hard × workers must be comfortably below total RAM. If that product exceeds your RAM, you will hit OOM under load.

4. Add Swap Space

Swap is not a permanent fix, but it gives the OOM killer more breathing room during traffic spikes and prevents hard crashes while you tune the configuration.

# Create a 2 GB swapfile
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make it persist across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Reduce swap aggressiveness (default 60 is too aggressive for a DB server)
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Verify
free -h

5. Optimize Cron Jobs

Cron threads run continuously and are a frequent source of slow memory growth. Limit them and stagger schedules.

# /etc/odoo/odoo.conf
max_cron_threads = 1

In the Odoo UI go to Settings → Technical → Automation → Scheduled Actions. Increase the interval of any cron that processes large record sets. For mail-fetching jobs and heavy report generation, consider scheduling them during off-peak hours.

6. Restart Odoo and Monitor

sudo systemctl restart odoo

# Watch memory usage in real time
watch -n 2 'free -h; echo; ps aux --sort=-%mem | grep python | head -10'

How DeployMonkey Handles This Automatically

Every instance deployed through DeployMonkey ships with a pre-tuned odoo.conf generated from your plan's allocated resources. Worker count, limit_memory_soft, and limit_memory_hard are all computed from the server's actual vCPU and RAM — you never have to calculate them manually.

DeployMonkey's monitoring stack tracks RSS per worker in real time. If any worker's memory approaches the hard limit repeatedly, the dashboard surfaces an alert so you can upgrade your plan or investigate a leaky custom module before the OOM killer strikes. Swap is provisioned automatically on all managed servers, sized relative to RAM.

On the Base, Pro, and Agency plans, the platform also enforces cron thread limits at the infrastructure level, ensuring background jobs cannot starve your HTTP workers of memory. If you need a custom cron profile — for example, a nightly data import that requires a larger memory ceiling — that can be configured through the instance settings panel without touching a command line.

Related Issues

• How to Configure Odoo Workers for Best Performance
• Odoo Slow? How to Diagnose and Fix Performance Issues
• How to Optimize PostgreSQL for Odoo
• Odoo Server Requirements

Frequently Asked Questions