前些天一个Nginx PHP项目上线后遭遇了性能问题，于是打算练练手，因为代码并不是我亲自写的，所以决定从系统层面入手看看能否做一些粗线条的优化。 首先，我发现服务的Backlog设置过小，这点可以通过ss命令查询Send-Q来确认： shell ss -lnRecv-Q Send-Q Loc
前些天一个Nginx PHP项目上线后遭遇了性能问题，于是打算练练手，因为代码并不是我亲自写的，所以决定从系统层面入手看看能否做一些粗线条的优化。
首先，我发现服务的Backlog设置过小，这点可以通过ss命令查询Send-Q来确认：
shell> ss -ln Recv-Q Send-Q Local Address:Port Peer Address:Port 0 511 *:80 *:* 0 128 127.0.0.1:9000 *:*
明显看出，Nginx的Backlog是511；PHP的Backlog是128，在高并发时易成为瓶颈。关于TCP队列的详细介绍，推荐阅读「?TCP queue 的一些问题」，此外，大家有兴趣的可以关注一下在Linux中?全连接和?半连接队列长度是如何计算的。
其次，我发现服务的进程数设置过少，Nginx的进程数好说，通过?worker_processes指令控制，按照CPU个数设置就行了，如果版本够的话，可以直接设置成auto。?PHP的进程数设置多少合适，并没有一个固定的答案，如果内存充足的话，我一般选择静态模式，并设置进程数为1024个，当然不能片面的以为进程数越多越好，不然调度会成问题。
关于PHP进程数的权衡，我建议大家阅读如下资料：
按照如上的分析，我在测试环境实施时，一切都非常顺利，不过在正式环境实施时，彻底被吓尿了：首先优化PHP，一切正常；接着优化Nginx，结果服务宕机，赶紧回滚了Nginx的优化，服务依然没有起死回生。无奈放出大招：重启服务器，尼玛好了！
转瞬之间经历了莫名其妙的大悲大喜，真让人无法承受，好在重启服务器之后一切都正常了，可以相对从容的查找问题的原因，其实错误日志里已经留下了线索：
setuid(99) failed (11: Resource temporarily unavailable)
原来出现了资源不足！确认一下到底是哪个用户：
shell> grep -w 99 /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin
恰好Nginx和PHP的子进程都是通过nobody用户启动的，看来问题就出在这里了，可是为什么测试环境正常，正式环境异常呢？原来差异出现在操作系统的版本上：虽然操作系统都是CentOS，但测试环境的版本是5.5，正式环境的版本是6.2，最要命的是新版的操作系统里多了一个限制用户进程数的配置文件，缺省设置是1024：
shell> cat /etc/security/limits.d/90-nproc.conf # Default limit for number of user's processes to prevent # accidental fork bombs. # See rhbz #432903 for reasoning. * soft nproc 1024
也就是说，nobody用户最多只能启动1024个进程。案例中，先优化的PHP，由于启动的进程数较多，一下子就花光了所有的资源配额，接着优化Nginx时，失败无法避免。
不过为什么重启服务器后一切看起来都正常了呢？这是启动顺序造成的：
shell> ls /etc/rc3.d/ | grep -E 'nginx|php' S55nginx S84php-fpm
也就是说，重启服务器后，Nginx先于PHP启动，由于Nginx的进程数较少，所以启动成功，接着PHP启动时，虽然依然会触发限制阈值，但大部分进程都能够启动成功，只有少部分进程启动失败，所以从表象上看，我们认为成功了。
如果这次优化引发的血案让你意犹未尽，可以继续阅读?ulimit限制之nproc问题。
原文地址：linux nginx优化php引发的问题, 感谢原作者分享。
