一次优化引发的血案

前些天一个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-fpm的max_chindren的一些误区
• Should PHP Workers Always Equal Number Of CPUs

按照如上的分析，我在测试环境实施时，一切都非常顺利，不过在正式环境实施时，彻底被吓尿了：首先优化PHP，一切正常；接着优化Nginx，结果服务宕机，赶紧回滚了Nginx的优化，服务依然没有起死回生，恍惚间我心想难不成修改Backlog把操作系统改坏了？不能够啊！无奈放出大招：重启服务器，尼玛好了！

转瞬之间经历了莫名其妙的大悲大喜，让人缓不过神来，好在重启服务器之后一切都正常了，可以相对从容的查找问题的原因，其实错误日志里已经留下了线索：

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.X，正式环境的版本是6.X，最要命的是新版的操作系统里多了一个限制用户进程数的配置文件，缺省设置是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

也就是说，任何用户最多只能启动1024个进程。案例中，先启动的PHP，由于进程数较多，一下子就用光了所有的资源配额，接着启动Nginx时，失败无法避免。

不过为什么重启服务器后一切看起来都正常了呢？这是启动顺序造成的：

shell> ls /etc/rc3.d/ | grep -E 'nginx|php'
S55nginx
S84php-fpm

也就是说，重启服务器后，Nginx先于PHP启动，由于Nginx的进程数较少，所以启动成功，接着PHP启动时，虽然还是会触发限制阈值，但大部分进程都能够启动成功，只有少部分进程启动失败，所以从表象上看，我们认为成功了。

如果这次优化引发的血案让你意犹未尽，可以继续阅读ulimit限制之nproc问题。