The common mistake is thinking that the error_log off directive disables logging.
If NGINX somehow uses all available FDs (for example, during a DoS attack), it becomes impossible even to log in to the machine to fix the issue. It is usually large enough, but it is worth verifying that the maximum number of file descriptors all NGINX worker processes might use ( worker_rlimit_nofile * worker_processes) is significantly less than fs.file‑max. There is also a system‑wide limit on the number of FDs, which you can set with the OS’s sysctl fs.file-max command. However, the method to use depends on how you start NGINX, whereas worker_rlimit_nofile works no matter how you start NGINX. The init script or systemd service manifest variables if you start NGINX as a service.The ulimit command if you start NGINX from a shell.UNIX offers several ways to set the number of FDs per process:
NGINX also uses an FD per log file and a couple FDs to communicate with master process, but usually these numbers are small compared to the number of FDs used for connections and files. As a caching server, NGINX behaves like a web server for cached responses and like a proxy server if the cache is empty or expired. When it acts as a proxy server, NGINX uses one FD each for the connection to the client and upstream server, and potentially a third FD for the file used to store the server’s response temporarily. When NGINX acts as a web server, it uses one FD for the client connection and one FD per served file, for a minimum of two FDs per client (but most web pages are built from many files). Here’s why more FDs are needed: each connection from an NGINX worker process to a client or upstream server consumes an FD. The fix is to set that value with the worker_rlimit_nofile directive in the main configuration context. The common configuration mistake is not increasing the limit on FDs to at least twice the value of worker_connections. Indeed, the default nf file we distribute with NGINX Open Source binaries and NGINX Plus increases it to 1024. In modern UNIX distributions, the default limit is 1024.įor all but the smallest NGINX deployments, a limit of 512 connections per worker is probably too small. But it’s important to keep in mind that ultimately there is another limit on the number of simultaneous connections per worker: the operating system limit on the maximum number of file descriptors (FDs) allocated to each process. All types of connections (for example, connections with proxied servers) count against the maximum, not just client connections.
The worker_connections directive sets the maximum number of simultaneous connections that a NGINX worker process can have open (the default is 512). Mistake 1: Not Enough File Descriptors per Worker Not taking advantage of upstream groups.Using ip_hash when all traffic comes from the same /24 CIDR block.Forgetting how directive inheritance works.Not enabling keepalive connections to upstream servers.
#Same word different contexts how to
When we help NGINX users who are having problems, we often see the same configuration mistakes we’ve seen over and over in other users’ configurations – sometimes even in configurations written by fellow NGINX engineers! In this blog we look at 10 of the most common errors, explaining what’s wrong and how to fix it.
0 kommentar(er)
