当前位置: 首页>>技术问答>>正文


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

, , , ,

问题描述

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

以此munin内存报告为例:

php,ubuntu,memory-management,laravel,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升级之前没有这个问题,这里有一张图片来证明这一点。

php,ubuntu,memory-management,laravel,munin

也许我应该将我的问题改写为: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需要了解的两件事,

  1. 这是一个估计

  2. 它暗示了在最坏的情况下你需要多少内存(加上交换)。它取决于您当时的服务器工作负载。如果您的工作负载较低,则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限制

参考资料

本文由Ubuntu问答整理, 博文地址: https://ubuntuqa.com/article/6871.html,未经允许,请勿转载。