PHP 5.5, при каких обстоятельствах PHP вызывает очень высокую память

Я пытаюсь понять ситуацию, когда PHP не потребляет много памяти, но вместо этого вызывает очень высокий результат Committed_AS.

Возьмите этот отчет памяти мюнина, например:

munin memory

Как только я запускаю нашу очередь Laravel (10 ~ 30 рабочих), преданная память проходит через крышу. У нас есть 2G mem + 2G swap на этом экземпляре vps, и до сих пор существует около 600M неиспользуемой памяти (это около 30% бесплатно).

Если я понял Committed_AS правильно, это означало гарантию 99.9% out of memory, учитывая текущую рабочую нагрузку, и кажется чтобы предложить нам утроить нашу память VPS, чтобы быть в безопасности.

Я попытался уменьшить количество очередей от 30 до 10, но, как вы видите, зеленая линия довольно высока.

Что касается настройки: Laravel 4.1 с включенным opcache PHP 5.5. Выскочка script используется экземпляр spawn, например:

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, вот изображение, чтобы доказать это.

old munin memory

Возможно, мне следует перефразировать мой вопрос следующим образом: как точно вычисляются Committed_AS и как PHP влияет на него?

Обновлено 2014.1.29:

У меня была теория по этой проблеме: поскольку работник очереди laravel фактически использует PHP sleep(), ожидая нового задания из очереди (в моем случае beanstalkd), это предполагает, что высокая оценка Committed_AS обусловлена относительно низкая рабочая нагрузка и относительно высокое потребление памяти.

Это имеет смысл, поскольку я вижу Committed_AS ~ = avg. memory usage / avg. workload. Поскольку PHP sleep() корректно, мало используется процессор; но все же память, которую он потребляет, по-прежнему сохраняется. Какой результат в мышлении сервера: эй, вы используете так много памяти (в среднем), даже когда загрузка минимальна (в среднем), вы должны быть лучше подготовлены к более высокой нагрузке (но в этом случае более высокая загрузка не приводит к увеличению объема памяти след)

Если кто-то хочет проверить эту теорию, я буду рад наградить их наградой.

Ответы

Ответ 1

Недавно я нашел основную причину этой проблемы с высокой памятью: Настройки PHP 5.5 OPcache.

Похоже, что put opcache.memory_consumption = 256 заставляет каждый процесс PHP резервировать гораздо больше виртуальной памяти (можно увидеть в столбце VIRT в вашей команде top), в результате чего Munin оценивает потенциальную память, которая будет намного выше.

Количество очередей laravel, которые мы выполняем в фоновом режиме, только преувеличивает проблему.

Поместив opcache.memory_consumption в рекомендуется 128 MB (мы действительно не использовали все эти 256 МБ эффективно), мы вырезали оценку значение в два раза, в сочетании с недавним обновлением ОЗУ на нашем сервере, оценка составляет около 3 ГБ, гораздо более разумная и в пределах нашего общего предела RAM

Ответ 2

Две вещи, которые вам нужно понять о Committed_AS,

  • Это оценка
  • В нем указано, сколько памяти вам потребуется в худшем случае (плюс своп). Это зависит от рабочей нагрузки вашего сервера в то время. Если у вас более низкая рабочая нагрузка, Committed_AS будет ниже и наоборот.

Если это не проблема с предыдущей итерацией очереди фреймов и при условии, что вы не ввели какие-либо новые изменения кода в производственную среду, вам нужно сравнить две итерации. Возможно, разверните еще одну коробку и выполните несколько тестов. Вы также можете профилировать приложение с помощью xdebug или zend_debugger, чтобы обнаружить возможные причинные факторы с помощью самого кода. Другим полезным инструментом является strace.

Все самое лучшее, вам это понадобится!

Ответ 3

Committed_AS - фактический размер, который ядро ​​фактически обещало процессам. И queues работает независимо и не имеет ничего общего с PHP или Laravel. В дополнение к тому, что сказал Rijndael, я рекомендую установить New Relic которые могут быть использованы для выяснения проблемы.

Совет. Я заметил огромное снижение нагрузки на сервер с помощью комбинации NginX-HHVM. Попробуйте.