NGINX Worker Resource Limit Configuration Guide

📋 Overview

The worker_rlimit_nofile directive is a critical NGINX configuration parameter that controls the maximum number of files that can be opened simultaneously by worker processes. This guide provides comprehensive instructions on setting, verifying, and adjusting this limit to ensure optimal performance for WordPress sites.

💡 Key Concept: The default open file limit may be insufficient for high-traffic WordPress sites. Setting an appropriate limit prevents the "too many open files" error and ensures smooth operation under load.

⚙️ Initial Configuration

The initial configuration sets the open file limit to 30,000, which is suitable for most WordPress installations. This value is set in the main context of the NGINX configuration file.

NGINX Main Context Configuration

worker_rlimit_nofile 30000;
worker_priority -10;
timer_resolution 100ms;
pcre_jit on;

⚠️ Important: The value 30,000 represents the maximum number of file descriptors (files, sockets, pipes) that each NGINX worker process can open. If you encounter "too many open files" errors, you'll need to increase this value.

📊 Configuration Process Flow

Step-by-Step Configuration Workflow

1. Check Current Open File Limit

⬇

2. Modify NGINX Configuration

⬇

3. Test Configuration Syntax

⬇

4. Reload NGINX Service

⬇

5. Verify New Limit is Active

🔧 Step-by-Step Implementation

1Determine Current NGINX Process ID

Before checking the current limit, you need to identify the NGINX worker process ID. Use the ps command with grep to filter for NGINX processes running under the www-data user.

Command to Find Process ID

ps aux | grep www-data

Understanding the command:

ps aux - Lists all running processes with detailed information
| - Pipe symbol redirects output to the next command
grep www-data - Filters results to show only www-data processes

🔍 Example Output:
www-data 42034 0.0 1.2 nginx: worker process
The process ID (PID) is 42034 in this example (second column).

2View Current Open File Limits

Once you have the process ID, use the cat command to view the current resource limits for that specific process.

Command to Check Limits (Replace XXX with actual PID)

cat /proc/XXX/limits

Example with PID 42034

cat /proc/42034/limits

Expected Output:

Limit                     Soft Limit    Hard Limit    Units
Max open files            30000         30000         files
Max locked memory         65536         65536         bytes
Max processes             7862          7862          processes

3Modify NGINX Configuration

To change the open file limit, edit the main NGINX configuration file and adjust the worker_rlimit_nofile directive value.

Open Configuration File

cd /etc/nginx
sudo nano nginx.conf

Locate the worker_rlimit_nofile directive in the main context and change its value:

Increase Limit from 30,000 to 45,000

worker_rlimit_nofile 45000;

4Test and Apply Configuration

Always test the NGINX configuration syntax before reloading to prevent service disruptions.

Test Configuration Syntax

sudo nginx -t

Expected Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload NGINX to Apply Changes

sudo systemctl reload nginx

5Verify New Limit is Active

After reloading NGINX, verify that the new limit has been applied by repeating the process ID check and limit verification.

Find New Process ID and Verify

ps aux | grep www-data
cat /proc/NEW_PID/limits

✅ Verification Example:
After configuration, you should see:
Max open files 45000 45000 files

📈 Recommended Values Based on Traffic

Site Traffic Level	Recommended Value	Description
Small WordPress Site	30,000	Default configuration suitable for low to moderate traffic
Medium WordPress Site	45,000	Recommended for sites with moderate to high traffic
High-Traffic WordPress Site	60,000 - 100,000	For sites experiencing very high concurrent connections
Enterprise Level	100,000+	Custom configuration for enterprise-scale deployments

💻 Streamlining Workflow with Bash Aliases

Repeatedly typing lengthy commands can be time-consuming. Bash aliases provide shortcuts that significantly improve workflow efficiency. Instead of typing sudo nginx -t every time, you can create an alias like ngt.

Creating the Aliases File

Create/Edit .bash_aliases File

cd ~
nano .bash_aliases

Essential NGINX Aliases

Alias: ngt (NGINX Test)

alias ngt='sudo nginx -t'

Usage: Type ngt instead of sudo nginx -t to test NGINX configuration syntax.

Alias: ngr (NGINX Reload)

alias ngr='sudo systemctl reload nginx'

Usage: Type ngr instead of sudo systemctl reload nginx to reload NGINX.

Alias: fpmr (PHP-FPM Restart)

alias fpmr='sudo systemctl restart php8.3-fpm'

Usage: Type fpmr instead of the full command to restart PHP-FPM.

Alias: ngsa (Navigate to Sites-Available)

alias ngsa='cd /etc/nginx/sites-available/ && ls'

Usage: Type ngsa to navigate to the sites-available directory and list its contents.

Alias: ngin (Navigate to Includes)

alias ngin='cd /etc/nginx/includes/ && ls'

Usage: Type ngin to navigate to the includes directory and list its contents.

💡 Command Chaining: The && operator chains commands together, ensuring the second command only runs if the first succeeds. For example, in alias ngin='cd /etc/nginx/includes/ && ls', the ls command only executes if the cd command succeeds.

Complete Alias Configuration

Complete .bash_aliases File

# System Update Alias
alias server_update='sudo apt update && sudo apt upgrade && sudo apt autoremove'

# NGINX Aliases
alias ngt='sudo nginx -t'
alias ngr='sudo systemctl reload nginx'
alias ngsa='cd /etc/nginx/sites-available/ && ls'
alias ngin='cd /etc/nginx/includes/ && ls'

# PHP-FPM Alias
alias fpmr='sudo systemctl restart php8.3-fpm'

# MariaDB Alias
alias mariare='sudo systemctl restart mariadb'

Activating Aliases

After creating or modifying the .bash_aliases file, you must log out and log back in for the aliases to take effect. Alternatively, use the su command to switch to your user account.

Activate Aliases Using su Command

su username

⚠️ Important Naming Convention: Never name an alias the same as an existing command. For example, don't create an alias named ls because it will override the original ls command, potentially causing unexpected behavior.

🏗️ NGINX Worker Process Architecture

How worker_rlimit_nofile Affects NGINX

🔍 Troubleshooting

Common Error: "Too Many Open Files"

Error Message: This error can appear in web browsers or server logs when the open file limit is exceeded.

Solution Steps:

Check current limit using the process described above
Increase the worker_rlimit_nofile value (e.g., from 30,000 to 45,000)
Test NGINX configuration: sudo nginx -t
Reload NGINX: sudo systemctl reload nginx
Verify the new limit is in effect

Verification Checklist

✅ Before proceeding, ensure:

Configuration syntax test passes without errors
NGINX service reloads successfully
New process ID is different from the old one (indicates successful reload)
Soft and hard limits both show the new value
No errors appear in error logs: tail -f /var/log/nginx/error.log

✨ Best Practices

Configuration Management

Always backup: Create backups before modifying configuration files (sudo cp nginx.conf nginx.conf.bak)
Test first: Always run sudo nginx -t before reloading
Monitor logs: Watch error logs when making changes to catch issues immediately
Document changes: Keep notes on why specific values were chosen
Start conservative: Begin with 30,000 and only increase if needed

Performance Optimization

Match your workload: Choose values based on actual site traffic and requirements
Consider system resources: Higher limits consume more memory
Monitor usage: Use tools like lsof to monitor actual file descriptor usage
Balance with worker_connections: Ensure open file limits support your connection limits

📌 Quick Reference Commands

Task	Command	Alias (if configured)
Find NGINX process ID	`ps aux \| grep www-data`	-
Check process limits	`cat /proc/PID/limits`	-
Edit NGINX config	`sudo nano /etc/nginx/nginx.conf`	-
Test configuration	`sudo nginx -t`	`ngt`
Reload NGINX	`sudo systemctl reload nginx`	`ngr`
Restart PHP-FPM	`sudo systemctl restart php8.3-fpm`	`fpmr`
View error log	`tail -f /var/log/nginx/error.log`	-

📝 Complete Example Scenario

Scenario: Increasing Limit from 30,000 to 45,000

Step 1: Check current configuration

$ ps aux | grep www-data
www-data  42034  0.0  1.2  nginx: worker process

$ cat /proc/42034/limits
Max open files            30000         30000         files

Step 2: Modify configuration

$ sudo nano /etc/nginx/nginx.conf

# Change this line:
worker_rlimit_nofile 30000;

# To:
worker_rlimit_nofile 45000;

Step 3: Test and apply

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

$ sudo systemctl reload nginx

Step 4: Verify new configuration

$ ps aux | grep www-data
www-data  42115  0.0  1.2  nginx: worker process

$ cat /proc/42115/limits
Max open files            45000         45000         files

✅ Success! The limit has been successfully increased from 30,000 to 45,000 and verified.

🎯 Conclusion

Properly configuring the worker_rlimit_nofile directive is essential for maintaining high-performance WordPress sites. By following this guide, you can:

Set appropriate open file limits based on your site's traffic
Prevent "too many open files" errors
Verify that configuration changes are applied correctly
Streamline your workflow with bash aliases
Troubleshoot and resolve common issues

💡 Remember: Start with the recommended value of 30,000 for most WordPress sites. Only increase this value if you experience issues or have specific high-traffic requirements. Always test configuration changes before applying them to production environments.