关于nginx服务器重大配置失误的发现（来自旭哥）

今天早上登录92号机器巡查，发现nginx主配置文件中有以下定义：
worker_processes  8;
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
events {
    worker_connections  5196;
}


全是注释，表示使用默认的日志级别，默认的级别是error,对一个重要服务，仅仅记录error级别日志是远远不够的，我的习惯和经验是尽量记录为notice级别，以便及时发现问题，顺手修改为:
error_log  logs/error.log  notice;

nginx -s reload之后，在error.log中发现以下警告日志：
5196 worker_connections are more than open file resource limit: 1024
显然，nginx单个进程连接数被限制为1024，一共启用8进程，理论上nginx同时最多能打开8*1024个连接（这包括客户端、到后端机器的连接），对我们的应用理论上nginx最多同时能为1024*8/2个客户端（4096）服务，显然这个值配置的太低了。
高并发系统中，worker_connections应该配置尽可能高一些（如64K 65535）,以便让nginx能充分利用硬件资源，能处理更多连接。

解决办法：
1. 配置nginx错误日志级别为notice
2. 配置nginx子进程最大连接数至少64K
2. 配置open_file_limit, 两种方式均可
   A. 系统中默认配置/etc/security/limits.conf
   B. nginx配置中全局指定：
   worker_rlimit_core 0;
   worker_rlimit_nofile 65535;

说明：这两项的默认值与系统的limits配置一致，但系统的默认值对高并发系统来说太保守了，需要提升。

扩展总结：对任何一个进程，都会受这些限制的影响（这是Linux的系统保护机制），要特别留意这两项参数的配置。
FPM：rlimit_files rlimit_core
MySQL: open_files_limit max_connections
对其它应用，如果在配置文件中没有此类参数的配置项，应该在启动脚本中指定：
ulimit -n 65535 -c 0
另外，如果条件允许，重要应用软件的日志级别一定要详细，推荐notice级别。