问题描述
我试图找出PHP不消耗大量内存但导致非常高的Committed_AS结果的情况。
以此munin内存报告为例：
一旦我开始我们的Laravel队列(10~30名工人)，承诺的 memory 就会通过屋顶。我们在这个vps实例上有2G内存+ 2G交换，到目前为止大约有600M未使用的内存(大约30％免费)。
如果我正确地执行了understand 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队列工作者在等待队列中的新作业(在我的情况下是beanstalkd)时实际上使用PHP sleep()，因此建议高Committed_AS估计是由于相对较低的工作负载和相对较高的内存消耗。
这是有道理的，因为我看到Committed_AS~ = avg. memory usage / avg. workload。正确地使用PHP sleep()，几乎没有使用CPU;然而它所消耗的任何 memory 仍然是保留的。这导致了服务器的思考：嘿，即使负载很小(平均)，你也会使用如此多的内存(平均而言)，你应该为更高的负载做好准备(但在这种情况下，更高的负载不会导致更高的内存)脚印)
如果有人想测试这个理论，我会很乐意给他们奖励。
最佳解决方法
有关Committed_AS需要了解的两件事，
-
这是一个估计
-
它暗示了在最坏的情况下你需要多少内存(加上交换)。它取决于您当时的服务器工作负载。如果您的工作负载较低，则Committed_AS将更低，反之亦然。
如果这不是框架队列的先前迭代的问题，并且假设您没有将任何新的代码更改推送到生产环境，那么您将需要比较两个迭代。也许旋转另一个盒子并运行一些测试。您还可以使用xdebug或zend_debugger对应用程序进行概要分析，以发现代码本身可能存在的因果因素。另一个有用的工具是strace。
一切顺利，你需要它！
次佳解决方法
我最近发现了这个高提交内存问题的根本原因：PHP 5.5 OPcache设置。
原来放置opcache.memory_consumption = 256会导致每个PHP进程保留更多的虚拟内存(可以在top命令的VIRT列中看到)，从而导致Munin估计潜在的提交内存要高得多。
我们在后台运行的laravel队列数量只会夸大问题。
通过将opcache.memory_consumption放到recommended 128 MB(我们真的没有有效地使用所有这256MB)，我们将估算值减少了一半，再加上我们服务器上最近的RAM升级，估计大约为3GB，更合理且内部我们的总RAM限制