PHP 5.5,在什么情况下PHP会导致非常高的提交内存

Question

我试图找出PHP不消耗大量内存但反而导致非常高的Committed_AS结果的情况.

以此munin内存报告为例:

一旦我开始我们的Laravel队列(10~30名工人),承诺的记忆就会通过屋顶.我们在这个vps实例上有2G内存+ 2G交换,到目前为止大约有600M未使用的内存(大约30%免费).

如果我理解 Committed_AS正确的话,那意味着99.9%保证out of memory在目前的工作量下没有问题,并且它似乎表明我们需要将vps内存增加三倍以保证安全.

我试图将队列数量从30减少到10左右,但正如你所看到的那样,绿线非常高.

至于设置:启用了PHP 5.5 opcache的Laravel 4.1.我们使用spawn实例的upstart脚本如下:

instance $N

exec start-stop-daemon --start --make-pidfile --pidfile /var/run/laravel_queue.$N.pid --chuid $USER --chdir $HOME --exec /usr/bin/php artisan queue:listen -- --queue=$N --timeout=60 --delay=120 --sleep=30 --memory=32 --tries=3 >> /var/log/laravel_queue.$N.log 2>&1

我看到很多情况下高交换使用意味着内存不足,但我们的交换使用率很低,所以我不确定在这里适当的故障排除步骤.

PS:我们在Laravel 4.1和vps升级之前没有这个问题,这里有一张图片来证明这一点.

也许我应该将我的问题改写为:Committed_AS如何准确计算以及PHP如何计算它？

---

更新2014.1.29:

我有一个关于这个问题的理论:由于laravel队列工作者sleep()在等待队列中的新作业时实际上使用PHP (在我的情况下beanstalkd),这表明高Committed_AS估计是由于相对较低的工作负载和相对较高的内存消耗.

这看起来很有意义Committed_AS〜= avg. memory usage / avg. workload.sleep()正确的PHP ,使用很少甚至没有CPU; 然而它所消耗的任何记忆仍然是保留的.这导致了服务器的思考:嘿,即使负载很小(平均),你也会使用如此多的内存(平均而言),你应该为更高的负载做好准备(但在这种情况下,更高的负载不会导致更高的内存)脚印)

如果有人想测试这个理论,我会很乐意给他们奖励.

Answer 1

我最近找到了这个高提交内存问题的根本原因：PHP 5.5 OPcache 设置。

结果 putopcache.memory_consumption = 256导致每个 PHP 进程保留更多的虚拟内存（可以在命令中的 VIRT 列中看到top），从而导致 Munin 估计潜在的提交内存要高得多。

我们在后台运行的 Laravel 队列数量只会加剧问题。

通过使用opcache.memory_consumption建议的 128 MB（我们确实没有有效地使用所有这些 256MB），我们已将估计值削减了一半，再加上最近对我们服务器的 RAM 升级，估计约为 3GB，更加合理，并且在我们的总 RAM 限制