最近我切换到NGINX / PHP-FPM来运行我的论坛。
大多数时候,网站运行精美,认真快速,我真的很高兴。 它在一个13核心/ 30 + GB的内存实例与AWS,如此充足的资源(在8核心,16GB之前与Apache。)
那么,会发生什么呢,大多数时候我们有6到7个PHP-FPM进程,并且都和世界一样好;
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27676 apache 20 0 499m 34m 19m R 49.2 0.1 0:06.33 php-fpm 27669 apache 20 0 508m 48m 24m R 48.2 0.1 0:10.84 php-fpm 27661 apache 20 0 534m 75m 26m R 45.9 0.2 0:16.18 php-fpm 27671 apache 20 0 531m 69m 21m R 43.9 0.2 0:09.85 php-fpm 27672 apache 20 0 501m 41m 23m R 32.9 0.1 0:09.18 php-fpm 27702 apache 20 0 508m 40m 16m R 23.6 0.1 0:00.94 php-fpm
那么,还挺好。 大量的CPU使用,但只有less数,所以它还挺好。
然后,看起来无处不在,我产生了一堆进程(上次我们有52个), 每个进程都使用8%的CPU。 你不需要擅长这个就知道52 * 8是很多的。
现在,我有max_children现在设置为40(现在是50)
pm.max_children = 40 pm.start_servers = 4 pm.min_spare_servers = 2 pm.max_spare_servers = 6 pm.max_requests = 100
内存限制在php.ini是128mb。
所以,我明白为什么我得到这么多的进程 – 这很好,我已经configuration好了。 我很好奇的是,如果我们每个进程拥有8%的cpu,那太多了吗? 而且,也许我的stream程还活得太久了?
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 26575 0.0 0.0 499572 4944 ? Ss 18:23 0:01 php-fpm: master process (/etc/php-fpm.conf) apache 28161 16.1 0.1 516644 47588 ? S 19:06 0:08 php-fpm: pool www apache 28164 18.0 0.1 525044 59644 ? S 19:06 0:07 php-fpm: pool www apache 28166 18.6 0.1 513152 41388 ? R 19:06 0:06 php-fpm: pool www apache 28167 23.2 0.1 515520 47092 ? S 19:06 0:07 php-fpm: pool www apache 28168 15.2 0.1 515804 49320 ? S 19:06 0:04 php-fpm: pool www apache 28171 17.3 0.1 514484 43752 ? S 19:06 0:04 php-fpm: pool www
当我写这篇文章的时候,它的下午7点08分 – 所以孩子们的stream程已经跑了2分钟,可能在那个时候服务了很多(Theres 700人在论坛上)。
所以 – 超级热衷于听取意见/批评/意见。 我最近有很多停机时间,我正在重新设置Apache,我很想坚持下去。
提前致谢。
编辑
这是Bitnami图表显示峰值和它们发生的速度(这是24小时) 
编辑#2
nginx.conf可以在这里find。
编辑#3
我撞上了我的号码。 它看起来不错,但仍然让我有点紧张。
pm.max_children = 100 pm.start_servers = 25 pm.min_spare_servers = 25 pm.max_spare_servers = 50 pm.max_requests = 500
编辑#4
所以,我还有几次停机,我已经设置了Splunk和New Relic来帮助我监视正在发生的事情。 看来没有CPU等待时间,我仍然有空闲的内存。
top - 17:30:37 up 10 days, 19:20, 2 users, load average: 24.61, 37.34, 25.68 Tasks: 151 total, 20 running, 131 sleeping, 0 stopped, 0 zombie Cpu0 : 71.8%us, 27.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu1 : 73.7%us, 26.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 70.8%us, 29.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 69.3%us, 30.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 35062648k total, 28747980k used, 6314668k free, 438032k buffers Swap: 0k total, 0k used, 0k free, 16527768k cached
看着Splunk似乎不像它的stream量 – 我受到了Googlebot的大量攻击,我对此感到怀疑,但没有具体的。
那么,还挺好。 大量的CPU使用,但只有less数,所以它还挺好
一个进程的工作量由它使用的CPU数量给出 – 因此它是%使用率x被使用的时间。 所以如果你的PHP进程使用了大量的CPU,那通常是一件好事 – 这意味着它不会等待其他的事情发生。 从系统pipe理员的angular度来看,您可以使更多的CPU可用于其他任务 – 但是您将增加PHP进程处理请求所花费的时间。
当然,如果请求以稳定的速度进入,花费更长的时间来处理它们意味着在任何时候都会有更多的进程工作(或者等待被调度),而更大的内存占用意味着更less的可用于VFScaching的内存。 还有一个风险是调度程序将开始抢占任务,而不是让它们进行,从而降低整体吞吐量。
因此,你应该瞄准高CPU使用率! (但是负载很低)。
内存限制在php.ini是128mb
这是相当高的,但由于CPU使用率很高,这表明它没有太多的问题,除非每个请求花费很长时间来完成,并做了大量的垃圾回收 – 在这种情况下,通过减less垃圾回收内存限制实际上可以提高性能。
最近我有这么多的停工
值得一提的是,APC比Xcache更可靠 – 这似乎是我在别处读到的趋势。 没有Zend Optimizer +的任何经验/数据,这将与未来版本的PHP捆绑在一起。
我正在重新设置Apache,我很想坚持下去
pre-fork apache + mod_php比nginx + php-fpm在交通量较低的情况下要快得多 – 但是当nginx的加载/请求速率相对于硬件容量来说是中等偏高的时候,似乎有一个巨大的优势是)。
如果是我的话,我会仔细观察日志,看是否由于stream量增加/stream量configuration文件的改变/响应时间的改变。 也很难在caching和代码。 您可能会考虑暂时运行一个针对实时站点的分析器(对于生产系统使用xhprof而不是xdebug)。