If you’re running Nginx as a frontend to Artifactory, you may bump into your OS's/Nginx's default open file descriptors limit. When this happens, Nginx's error.log might show something like this:
2010/04/16 13:24:16 [crit] 21974#0: *3188937 open() “/usr/local/nginx/..” failed (24: Too many open files), client: … server: foo.com, request: “GET /artifactory/.. HTTP/1.1”, upstream: “http://localhost:8081/artifactory..”, host: “foo.com”
You can generate a list of the default limits for given Linux machine processes by running:cat /proc/$PID/limits
cat /proc/$PID/limits
Note
Using Nginx buffering may cause some issues with Artifactory. Therefore, you might consider turning off proxy_request buffering. More information is available here.
By default, Nginx uses proxy_buffering. This means that when a client makes a request, Nginx buffers the upstream response payload to disk. Normally, Nginx saves those files to a temporary path and cleans up after itself when the request is completed. However, errors such as the one mentioned above can cause Nginx to stop cleaning up those temporary files. As a result, your disk space can fill up very fast, with clean-ups occurring only when you shut down the Nginx process.
A command such as:
lsof -a +L1 /var
might show some file descriptors with the term (deleted) next to them. Their existence is technically normal. However, if you see a "deleted" entry that isn't being cleaned up after a while, something could be wrong. And it’s a problem that can prevent your OS from being able to free up the disk space that’s being consumed by the un-cleaned up file handle.
If you’re using systemd, follow the steps here to increase your Nginx max open files setting.