17

我试图找出 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 queue workersleep()在等待队列中的新作业时实际上使用 PHP（在我的情况下beanstalkd），这表明高Committed_AS估计是由于相对较低的工作量和相对较高的内存消耗。

正如我所见，这是有道理的Committed_AS~= avg. memory usage / avg. workload。与 PHP 一样sleep()，几乎没有使用 CPU；但是它消耗的任何内存仍然是保留的。这导致服务器思考：嘿，即使负载很小（平均），您也使用了这么多内存（平均），您应该为更高的负载做好更好的准备（但在这种情况下，更高的负载不会导致更高的内存脚印）

如果有人想测试这个理论，我很乐意将赏金奖励给他们。

4

3 回答 3

2

关于 Committed_AS，您需要了解两件事，

  1. 这是一个估计
  2. 它暗示了在最坏的情况下您需要多少内存（加上交换）。这取决于您当时的服务器工作量。如果您的工作量较低，则 Committed_AS 将较低，反之亦然。

如果这不是框架队列的先前迭代的问题并且假设您没有将任何新的代码更改推送到生产环境，那么您将需要比较两个迭代。也许启动另一个盒子并运行一些测试。您还可以使用 xdebug 或 zend_debugger 分析应用程序，以发现代码本身可能的因果因素。另一个有用的工具是 strace。

一切顺利，您将需要它！

于 2014-01-27T18:58:49.890 回答
1

我最近发现了这个高承诺内存问题的根本原因：PHP 5.5 OPcache settings。

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

我们在后台运行的 laravel 队列的数量只会夸大这个问题。

通过设置opcache.memory_consumption推荐的128 MB（我们实际上并没有有效地使用所有这些 256MB），我们将估算值减少了一半，再加上我们服务器上最近的 RAM 升级，估算值在 3GB 左右，更加合理且在我们的总内存限制

于 2014-05-02T05:53:33.007 回答
0

Committed_AS是内核实际承诺处理的实际大小。并且queues独立运行，和Rijndael说的没什么关系PHP，Laravel.我推荐安装New Relic，可以用来找出问题。

提示：我注意到 NginX-HHVM 组合大大减少了服务器负载。试试看。

于 2014-02-01T14:29:38.853 回答