nginx 子进程 woker process 启动失败的问题

问题：

重启nginx服务，worker process 子进程启动失败，启动的都是master进程：

负载急速升高（平常都是4-5），占用CPU资源多的前十进程都是nginx ：

nginx 错误日志里频繁记录：

// :: [alert] #: worker process  exited on signal
// :: [alert] #: worker process  exited on signal
// :: [alert] #: worker process  exited on signal
// :: [alert] #: worker process  exited on signal
// :: [alert] #: worker process  exited on signal 

查看dmesg 信息：

# dmesg |grep nginx
Out of memory: Kill process  (nginx) score  or sacrifice child

系统内存被耗尽，导致nginx进程频繁被 kill 掉。

分析：

没重启nginx前，服务一切正常。回想昨天对nginx的配置做了优化，而没有重启nginx测试。

优化的根据如下：

网上的nginx配置优化的文章，大多建议woker_rlimit_nofile 、woker_connections、ulimit -n 的值保持一致。

出现问题的nginx配置如下：

worker_processes 32;
worker_rlimit_nofile 1024000;

events {
　　worker_connections  1024000;
}

其实，这些参数的设置有个前提：

并发总数：max_clients = worker_processes * worker_connections 
nginx做反向代理的情况下，max_clients = （worker_processes * worker_connections）/ 4   # 一般都除以4, 经验所得。

因并发受IO的约束，worker_connections 值的设置跟物理内存大小有关，max_clients 的值必须小于操作系统理论情况下可以打开的最大文件数。

而操作系统可以打开的最大文件数和内存大小成正比，查看32G内存的机器上，理论情况下，可以打开的最大文件数：
#cat /proc/sys/fs/file-max
3262366

当max_clients < `cat /proc/sys/fs/file-max` 的值时，这样在操作系统可以承受的范围内。

worker_connections 的值需根据 worker_processes 进程数和系统可以打开的最大文件总数 适当地进行设置，也就是要根据系统的CPU和内存进行配置。

当然，实际的并发总数还会受 `ulimit -n` 值的限制。

根据上述的nginx配置：

max_clients = 32 * 1024000 = 32768000 远远大于 3262366 ，因此系统的CPU、内存资源才会被nginx进程耗尽。

解决：

修改nginx配置：

worker_processes ;
worker_rlimit_nofile ;

events {
　　worker_connections  ;
}

重启nginx服务，woker process 正常生成，服务器负载下降到4-5 。