When Nginx experiences a "Too many open files" error, it is usually because the system or process has reached the file descriptor limit. Solutions include: 1. Increase the soft and hard limits of Linux system, set the relevant parameters of nginx or run users in /etc/security/limits.conf; 2. Adjust the worker_connections value of Nginx to adapt to expected traffic and ensure reloaded configuration; 3. Increase the system-level file descriptor upper limit fs.file-max, edit /etc/sysctl.conf and apply changes; 4. Optimize log and resource usage, reduce unnecessary file handle usage, such as using open_log_file_cache, merging logs, avoiding redundant proxy connections, etc. After the adjustment is completed, you can monitor the actual number of open files through the lsof command.

When Nginx throws a “Too many open files” error, it usually means the system or process has hit its file descriptor limit. This can lead to failed connections, stalled services, or even crashes if not addressed.

Here's what typically causes this issue and how to handle it.

1. File Descriptor Limits in Linux

Linux systems impose limits on the number of file descriptors (FDs) that a process can open. These limits come in two flavors: soft and hard.

• Soft limit – What the process is currently allowed to use.
• Hard limit – The maximum value the soft limit can be raised to.

If Nginx reaches the soft limit, you'll see the “Too many open files” message in the logs. You can check current limits using:

 ulimit -n

To increase the limit, edit /etc/security/limits.conf and add:

 nginx soft nofile 65536
nginx hard nofile 65536

Or for the user running Nginx:

 www-data soft nofile 65536
www-data hard nofile 65536

Also make sure pam_limits.so is enabled in your PAM config so these settings are applied at login.

2. Nginx Worker Connections Setting

In nginx.conf , there's a directive called worker_connections . It defines how many simulateneous connections each worker process can handle.

This line might look like:

 events {
    worker_connections 1024;
}

Each connection uses at least one file descriptor — sometimes more if SSL or upstream connections are involved.

So if you're handling thousands of concurrent users, the default 1024 may be too low.

You should:

• Estimate your expected traffic.
• Multiply by the average FDs per connection (often 2–4).
• Set worker_connections higher than that.

Don't forget to reload Nginx after changing this:

 nginx -s reload

Also keep an eye on the total number of worker processes multipleplied by worker_connections , because that gives you the total max connections across all workers.

3. System-wide File Descriptor Cap

Even if you configure Nginx and user limits correctly, the entire system also has a global FD cap controlled by fs.file-max .

Check current value with:

 cat /proc/sys/fs/file-max

If it's low, raise it by editing /etc/sysctl.conf :

 fs.file-max = 2097152

Then apply changes:

 sysctl -p

This step is often overlooked but essential under high load. Think of it as the ceiling for all processes combined — including Nginx, PHP, MySQL, etc.

4. Open Log Files and Unused Resources

Every access log, error log, or upstream connection Nginx opens consumes a file descriptor.

If you have dozens of virtual hosts, each writing to separate logs, those add up fast.

Some things to consider:

• Use open_log_file_cache to reduce overhead.
• Consolidate logs where possible.
• Avoid unnecessary upstream blocks or proxy connections.

Also, some modules or misconfigured third-party integrations might leak FDs over time — especially if they don't close upstream connections properly.

Basically, the "Too many open files" error comes down to limits being too low for the workload. Check ulimits, tweak worker_connections , raise system-wide caps, and minimize unequisany file handles. Once configured, monitor with tools like lsof -p $(pidof nginx) to see what's actually open.

The above is the detailed content of What causes a 'Too many open files' error in Nginx?. For more information, please follow other related articles on the PHP Chinese website!