欢迎光临
我们一直在努力

一次优化引发的血案

前些天一个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的优化,服务依然没有起死回生,恍惚间我心想难不成修改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问题

赞(3) 打赏
转载请注明来源:IT技术资讯 » 一次优化引发的血案

评论 抢沙发

评论前必须登录!

 

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏