Nginx日志报错如下，是因为Nginx进程打开文件数过多了。
解决办法：
1、调整/etc/security/limits.conf的nofile/nproc，需要重启机器才能生效
2、调整Nginx配置
worker_processes 8;
# set open fd limit to 655350
worker_rlimit_nofile 655350;
events {
use epoll;
worker_connections 65535;
multi_accept on;
}
worker_connections 指令用于设置 NGINX worker 进程可以打开的最大并发连接数（默认为 512）。所有类型的连接（例如与代理服务器的连接）都计入最大值，而不仅仅是客户端连接。但重要的是要记住，最终每个 worker 的并发连接数还有另一个限制：操作系统对分配给每个进程的文件描述符 (file descriptor，即FD) 最大数量的限制。在现代 UNIX 发行版中，默认限制为 1024。
对于除最小的NGINX部署之外的 所有部署，将每个 worker 的连接数限制为 512 可能太少了。事实上，我们将随 NGINX 开源版二进制文件和 NGINX Plus 一起分发的默认 nginx.conf 文件将其增加到 1024。
常见的配置错误是没有将 FD 的限制增加到至少两倍的 worker_connections 的值。解决方法是在主配置上下文中使用 worker_rlimit_nofile 指令设置该值。
这就是需要更多 FD 的原因：从 NGINX worker 进程到客户端或上游服务器的每个连接都消耗一个 FD。当 NGINX 充当 Web 服务器时，每个客户端连接使用一个 FD，每个服务的文件使用一个 FD，这样每个客户端至少需两个 FD（但大多数网页是由许多文件构建的）。当充当代理服务器时，NGINX 分别使用一个 FD 连接客户端和上游服务器，并可能用到第三个 FD 给用于临时存储服务器响应的文件。作为缓存服务器时，NGINX 的行为类似于缓存响应的 Web 服务器，如果缓存为空或过期，则类似于代理服务器。
NGINX 为每个日志文件使用一个 FD，并会用几个 FD 与主进程通信，但与用于连接和文件的 FD 数量相比，这些数量通常很少。
FD 的数量也有系统范围的限制，您可以使用操作系统的 sysctl fs.file-max 命令进行设置。它通常足够大，但有必要验证所有 NGINX worker 进程可能使用的文件描述符的最大数量 (worker_rlimit_nofile * worker_processes) 明显小于 fs.file‑max。如果 NGINX 以某种方式使用了所有可用的 FD（例如，在 DoS 攻击期间），此时甚至都无法登录机器来解决问题。
