我试图找出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; 然而它所消耗的任何记忆仍然是保留的.这导致了服务器的思考:嘿,即使负载很小(平均),你也会使用如此多的内存(平均而言),你应该为更高的负载做好准备(但在这种情况下,更高的负载不会导致更高的内存)脚印)
如果有人想测试这个理论,我会很乐意给他们奖励.