The Root Cause Nginx Out of Memory (OOM) on Debian 11 typically occurs when the configured number of worker processes, combined with memory usage per active connection, exceeds the available system RAM and swap space. This often leads to the Linux OOM killer terminating Nginx processes to free up resources, causing service interruptions.

Quick Fix (CLI)

To immediately alleviate resource pressure and attempt to bring Nginx back online:

# 1. Temporarily reduce worker processes to 1 in nginx.conf
# This significantly lowers Nginx's memory footprint until a permanent solution is applied.
sudo sed -i 's/^\s*worker_processes\s\+.*;$/worker_processes 1;/' /etc/nginx/nginx.conf

# 2. Restart Nginx to apply the change
sudo systemctl restart nginx

# 3. Verify Nginx status and check recent logs for OOM killer messages
sudo systemctl status nginx
journalctl -u nginx --since "5 minutes ago" -n 50
dmesg -T | grep -i "oom-killer" | tail -n 10

Configuration Check

Edit the main Nginx configuration file to adjust resource parameters.

File to Edit: /etc/nginx/nginx.conf (or potentially included files in /etc/nginx/conf.d/ or /etc/nginx/sites-available/)

Lines to Change:

Adjust the worker_processes and worker_connections directives to match your server’s available memory. A common starting point for worker_processes is auto (one per CPU core), but if OOMing, reduce it.

# /etc/nginx/nginx.conf

# Adjust worker_processes:
# Set this to a number that allows Nginx to run without OOMing.
# A safe initial reduction is to 1 or 2, then slowly increase.
# Example: If your server has 2GB RAM, 2 worker processes might be a starting point.
worker_processes 2; # Changed from 'auto' or a higher number

events {
    # Adjust worker_connections:
    # Reduce if worker_processes * worker_connections uses too much RAM.
    # Each connection consumes memory for buffers.
    worker_connections 512; # Changed from 1024 or higher
}

http {
    # Consider reducing buffer sizes if they are excessively large and contribute to OOM.
    # Note: These are context-dependent and should only be reduced if identified as culprits.
    # Smaller buffers might lead to more disk I/O for large requests but save RAM.
    # client_body_buffer_size 32k;  # Default is often 8k or 16k
    # proxy_buffer_size 4k;         # Default is often 4k or 8k
    # proxy_buffers 4 4k;           # Default is often 4 8k
    # fastcgi_buffer_size 4k;
    # fastcgi_buffers 4 4k;
}

• Long-term Solution: If resource reduction compromises performance significantly, consider increasing the server’s RAM or adding/expanding swap space.

Verification

After making configuration changes, verify the syntax and restart Nginx.

# 1. Test Nginx configuration for syntax errors
sudo nginx -t

# 2. Restart Nginx to apply new configurations
sudo systemctl restart nginx

# 3. Check Nginx service status and recent logs
sudo systemctl status nginx
journalctl -u nginx --since "1 minute ago" -f

# 4. Monitor system memory usage to ensure stability
free -h

# 5. Check dmesg logs for any new OOM killer events
dmesg -T | grep -i "oom-killer" | tail -n 10