問題：
重啟nginx服務，worker process 子進程啟動失敗，啟動的都是master進程：
負載急速升高（平常都是4-5），占用CPU資源多的前十進程都是nginx ：
nginx 錯誤日志里頻繁記錄：
2016/07/15 11:54:19 [alert] 2930#0: worker process 2940 exited on signal 9
2016/07/15 11:54:19 [alert] 2930#0: worker process 2947 exited on signal 9
2016/07/15 11:54:19 [alert] 2930#0: worker process 2948 exited on signal 9
2016/07/15 11:54:19 [alert] 2930#0: worker process 2951 exited on signal 9
2016/07/15 11:54:19 [alert] 2930#0: worker process 2952 exited on signal 9
查看dmesg 信息：
# dmesg |grep nginx Out of memory: Kill process 43796 (nginx) score 480 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 32; worker_rlimit_nofile 51200; events { worker_connections 51200; }
重啟nginx服務，woker process 正常生成，服務器負載下降到4-5 。