老王:一次nginx+php优化引发的血案
前些天一个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问题。
- 转载请注明来源:IT学习网 网址:http://www.t086.com/ 向您的朋友推荐此文章
- 特别声明: 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载,但请务必注明出处和原始作者。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站,我们表示深深的谢意。如果本站转载的文章有版权问题请联系我们,我们会尽快予以更正。