PHP5-fpm失去控制 – 优化configuration

我有一个约80K的访问者(每天)的网站。

该站点位于linode.com上,并具有一个nodebalancer(与loadbalancer相同),后面有3个节点(2x linode 512和1x linode 1024)。

有时候stream量会让我失望,而且我的服务器变得没有反应(/ ping不能工作,并强制我的节点平衡器使节点不能旋转)。

我正在寻找一种方法来找出如何pipe理负载。 我已经在www.slow.log中寻找可能导致持续过程的原因。 也许你们可以帮我优化我的机器configuration?

我目前的configuration:

[www] user = www-data group = www-data listen = 127.0.0.1:9000 pm = dynamic pm.max_children = 70 pm.start_servers = 10 pm.min_spare_servers = 6 pm.max_spare_servers = 15 pm.process_idle_timeout = 10s; pm.max_requests = 200 pm.status_path = /status ping.path = /ping ping.response = pong slowlog = /var/log/$pool.log.slow request_slowlog_timeout = 60 chdir = / php_admin_value[error_log] = /var/log/fpm-php.www.log php_admin_flag[log_errors] = on 

编辑

这是build立操作负载的机器的顶部

 > top - 12:33:41 up 35 days, 44 min, 12 users, load average: 8.57, > 12.83, 12.21 Tasks: 193 total, 6 running, 187 sleeping, 0 stopped, 0 zombie Cpu(s): 36.6%us, 4.2%sy, 0.0%ni, 30.1%id, 0.0%wa, 0.0%hi, > 0.6%si, 28.5%st Mem: 1027516k total, 603048k used, 424468k free, 149040k buffers Swap: 524284k total, 110392k used, 413892k free, > 54064k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 31585 www-data 20 0 70600 16m 4388 R 37 1.7 0:09.92 php5-fpm > 31558 www-data 20 0 71352 17m 4344 R 33 1.7 0:18.18 php5-fpm > 31581 www-data 20 0 66480 13m 4312 S 22 1.3 0:12.08 php5-fpm > 31555 www-data 20 0 66220 12m 4344 S 19 1.3 0:16.51 php5-fpm > 31578 www-data 20 0 67244 13m 4352 S 19 1.4 0:10.53 php5-fpm > 31604 www-data 20 0 66992 13m 4180 S 15 1.3 0:05.31 php5-fpm > 31556 www-data 20 0 67244 13m 4324 S 15 1.4 0:16.53 php5-fpm > 31557 www-data 20 0 66476 12m 4340 R 13 1.3 0:17.35 php5-fpm > 31602 www-data 20 0 66468 13m 4320 S 12 1.3 0:06.59 php5-fpm > 31582 www-data 20 0 67244 13m 4328 S 11 1.4 0:11.18 php5-fpm > 31579 www-data 20 0 69328 15m 4344 R 11 1.6 0:10.76 php5-fpm > 31586 www-data 20 0 66736 13m 4308 S 9 1.3 0:08.17 php5-fpm > 31603 www-data 20 0 67504 14m 4324 S 8 1.4 0:06.35 php5-fpm > 31580 www-data 20 0 67244 13m 4336 S 7 1.4 0:11.06 php5-fpm > 31583 www-data 20 0 66736 13m 4300 S 7 1.3 0:10.80 php5-fpm > 31584 www-data 20 0 68024 14m 4356 S 6 1.4 0:10.17 php5-fpm > 31587 www-data 20 0 66736 13m 4328 S 6 1.3 0:08.18 php5-fpm > 31574 www-data 20 0 57856 52m 816 S 2 5.2 0:01.75 nginx > 31634 ward 20 0 2520 1040 736 R 1 0.1 0:00.09 top > 15554 ward 20 0 2520 552 264 R 1 0.1 59:04.40 top > 1023 root 0 -20 0 0 0 S 0 0.0 18:19.96 > kworker/0:1H > 31575 www-data 20 0 57856 52m 808 S 0 5.2 0:00.53 nginx > 31607 ward 20 0 8868 1292 772 S 0 0.1 0:00.01 sshd > > 1 root 20 0 2088 120 120 S 0 0.0 0:46.60 init > 2 root 20 0 0 0 0 S 0 0.0 0:03.17 kthreadd 

EDIT2:由growse提供的解决scheme反馈

我将3台服务器切换到静态池。 看起来好像现在控制下的负载更好。 我也增加max_requests到5000。

你可以看到下面每个服务器的池静态信息:

Server1:1024台机器

 pool: www process manager: static start time: 30/Dec/2012:12:48:23 +0100 start since: 489 accepted conn: 4311 listen queue: 0 max listen queue: 0 listen queue len: 128 idle processes: 35 active processes: 15 total processes: 50 max active processes: 35 max children reached: 0 

Server2:512机器

 pool: www process manager: static start time: 30/Dec/2012:12:45:40 +0100 start since: 709 accepted conn: 11010 listen queue: 0 max listen queue: 9 listen queue len: 128 idle processes: 33 active processes: 7 total processes: 40 max active processes: 40 max children reached: 0 

Server3:512机器

 pool: www process manager: static start time: 30/Dec/2012:12:38:25 +0100 start since: 1159 accepted conn: 21645 listen queue: 0 max listen queue: 129 listen queue len: 128 idle processes: 35 active processes: 5 total processes: 40 max active processes: 40 max children reached: 0 

现在所有的服务器运行更稳定,负载在1-2左右。

在考虑评论和build议三件事情之后,我要一瘸一拐地说:

  1. 从一个dynamic池切换到一个静态池 :假设你有一个FPM池,而你的服务器没有太多其他的东西,那么没有太多理由继续扩大你使用的进程数量。 挑选一些孩子,启动许多进程,然后离开它。

  2. 有更less的subprocess :最终,您的VPS最多有几个CPU。 每个FPMsubprocess可以同时处理一个请求,其他的只是排队等待。 所有有许多进程都接受来自队列的许多请求,然后强制它们竞争CPU使用率。 如果你有一个较小的池,并让突发stream量排队,你可能会有更好的结果。

  3. 增加FPMsubprocess的生命周期 :一旦服务器发出了200个请求,你就正在杀死每个子进程 。 这并不是很多,一阵stream量可能会看到一连串的儿童stream程被杀死和重生,这只会增加开销。 把这个增加到一个更大的值(比如说5000),看看会发生什么。

值得指出的是,很难知道这些build议是否有效,因为我不知道问题实际是什么(可能是硬件错误,或者是其他问题)。 这些对我来说似乎是合情合理的:试试看看它是否适合你的环境。