Php fpm жрет память

Обновлено: 05.07.2024

Опыт оптимизации php-fpm в Linux-процесс php-fpm занимает много памяти и не освобождает память

Недавно я обнаружил, что память блога всегда "съедается" каждые три раза. После входа в фоновый режим время от времени будут зависать. Сначала подозревалось, что свопа недостаточно. Поэтому я добавил несколько гигабайт свопа на хост VPS. Через некоторое время было обнаружено, что самый большой Своп медленно «съедался»!

Очевидно, что некоторые службы PHP занимали память VPS и не были выпущены, что привело к исчерпанию физической памяти и вызову Swap. Очевидно, что Swap не так эффективен, как физическая память, поэтому процесс зависает. Учитывая, слишком ли много тем и плагинов для Wordpress, это нормально.

В архитектуре LNMP PHP работает в режиме FastCGI. Согласно официальному заявлению, php-cgi будет освобождать всю память, используемую сценарием в конце каждого запроса, но не передает ее операционной системе, а продолжает ее удерживать. Ответьте на следующий запрос PHP. А php-fpm - это диспетчер процессов FastCGI, используемый для управления памятью и процессами php.

Следовательно, решение состоит в том, чтобы оптимизировать общее количество процессов и память, занимаемую одним процессом, с помощью php-fpm, чтобы решить проблему, когда процесс php-fpm занимает большую память и не освобождает память. Дополнительные методы оптимизации серверов Linux и опыт создания сайтов, а также:

PS: Обновлено 14 декабря 2018 г.,Если память и производительность вашего хоста VPS не очень хорошие, лучше всего включить кеширование в это время, чтобы значительно снизить потребление ресурсов:WordPress открывает метод ускорения кеширования Nginx fastcgi_cache - пример конфигурации Nginx。

1. Проанализируйте и оцените использование памяти php-fpm.

Если вы обнаружите, что хост VPS завис, сначала проверьте использование памяти. Обычно используемые команды: Top, Glances, Free и т. Д. Друзья, которые не знают эти команды, могут сначала проверить тему, выполняет ли станция копания:Сводка команд мониторинга системы Linux - главный процессор, память, дисковый ввод-вывод и т. Д. Для поиска узких мест в производительности。

Используйте команду Glances и снова нажмите m, чтобы просмотреть использование памяти текущим хост-процессом VPS, отсортированное по объему занятой памяти (или используйте команду Top и нажмите M, эффект тот же). Как показано ниже (щелкните, чтобы увеличить):

Это картина использования памяти процессом после перезапуска. Из сравнения до и после можно обнаружить, что по мере увеличения времени загрузки память, занимаемая php-fpm, становится все больше и больше, и, наконец, php-fpm исчерпывает всю физическую память VPS.

Просмотр текущего общего количества процессов php-fpm, команда: ps -ylC php-fpm --sort:rss . RSS - это занятая память. Как показано ниже:

Просмотр использования памяти и времени запуска текущего процесса php-fpm, Команда выглядит следующим образом:

Из рисунка ниже видно, что все текущие процессы php-fpm в среднем занимают 60-70 МБ памяти. Время запуска составляет 3:12, если это тот же день, в противном случае он будет отображаться как X месяц X день.

Просмотр среднего использования памяти текущим процессом php-fpmВообще говоря, память, занимаемая процессом php-fpm, составляет 30-40 МБ, а результат этого запроса - 60 МБ, что явно слишком много. Команда выглядит следующим образом:

2. Знакомство с описанием файла конфигурации php-fpm

php-fpm.conf - это файл конфигурации php-fpm, обычно путь: /usr/local/php/etc ,Как показано ниже:

Несколько важных параметров php-fpm.conf описаны следующим образом:

Ниже описаны три режима управления процессами PM:

pm = static, всегда поддерживать фиксированное количество дочерних процессов, это количество определяется pm.max_children, этот метод очень негибкий и обычно не используется по умолчанию.

pm = dynamic, фиксированное количество дочерних процессов (контролируемых pm.start_servers) можно понимать как минимальное количество дочерних процессов, а максимальное количество дочерних процессов контролируется pm.max_children, а количество дочерних процессов будет между максимальным и минимальным Изменение объема. Количество бездействующих дочерних процессов также можно контролировать с помощью двух других конфигураций: pm.min_spare_servers и pm.max_spare_servers. Если бездействующий дочерний процесс превышает pm.max_spare_servers, он будет убит. Менее pm.min_spare_servers запустит процесс (обратите внимание, что pm.max_spare_servers должно быть меньше pm.max_children).

pm = ondemand, этот режим противоположен pm = dynamic, ставя память на первое место, каждый неактивный процесс будет завершен через pm.process_idle_timeout секунд, если сервер не запрашивает в течение длительного времени, он будет только Есть основной процесс php-fpm. Недостатком является то, что если значение pm.process_idle_timeout слишком короткое, ошибка тайм-аута шлюза 504 может возникнуть в периоды пиковой нагрузки или если значение pm.process_idle_timeout слишком короткое, поэтому то, что больше подходит для pm = dynamic и pm = ondemand, зависит от реальной ситуации.

В-третьих, решить проблему большого использования памяти процессом php-fpm.

3.1 Настройте режим управления

Статический режим управления подходит для серверов с относительно большой памятью, а динамический - для серверов с небольшой памятью. Вы можете установить разумный диапазон pm.min_spare_servers и pm.max_spare_servers, чтобы количество процессов продолжало изменяться. Режим ondemand больше подходит для небольшой памяти, такой как память 512 МБ или 256 МБ, и сред, не требующих высокой доступности.

3.2 Уменьшите количество процессов php-fpm

Если память вашего хоста VPS исчерпана, вы можете проверить количество процессов php-fpm. Вычислить в соответствии с количеством процессов php-fpm = memory / 2/30. Количество процессов php-fpm, подходящих для 1 ГБ памяти, составляет 10- Между 20, это зависит от надстроек, загруженных вашим PHP.

3.3 пример конфигурации php-fpm

Вот демонстрация конфигурации VPS php-fpm с памятью 1 ГБ. При реальной работе значение настройки следует учитывать в зависимости от производительности самого сервера, PHP и т. Д.

В-четвертых, решите проблему, когда процесс php-fpm не освобождает память.

Вышеупомянутая проблема состоит в том, чтобы уменьшить использование памяти php-fpm за счет уменьшения общего количества процессов php-fpm. При фактическом использовании обнаружено, что процесс php-fpm по-прежнему имеет проблему занимать память в течение длительного времени, не освобождая ее. Решение состоит в том, чтобы уменьшить количество pm.max_requests.

Максимальное количество запросов max_requests, то есть, когда количество запросов, обработанных процессом PHP-CGI, накапливается до max_requests, процесс автоматически перезапускается, таким образом достигая цели освобождения памяти. В качестве примера возьмем настройку хоста VPS с 1 ГБ памяти (если установленное вами значение не достигло свободной памяти, вы можете продолжить его уменьшение):

Когда процесс php-fpm достигает значения, установленного pm.max_requests, процесс будет перезапущен для освобождения памяти. На приведенном ниже рисунке показан результат моего теста: видно, что процесс php-fpm принудительно завершается и память освобождается.

Пять, резюме

Для требований к большой памяти, параллельности и доступности рекомендуется использовать статический режим управления + максимум pm.max_children. Если это сервер с небольшой памятью, рекомендуется использовать динамический режим или режим по требованию, уменьшив при этом количество процессов pm.start_servers и pm.max_spare_servers.

Интеллектуальная рекомендация

совместный запрос mysql с тремя таблицами (таблица сотрудников, таблица отделов, таблица зарплат)

1. Краткое изложение проблемы: (внизу есть инструкция по созданию таблицы, копирование можно непосредственно практиковать с помощью (mysql)) Найдите отделы, в которых есть хотя бы один сотрудник. Отоб.

[Загрузчик классов обучения JVM] Третий день пользовательского контента, связанного с загрузчиком классов

IP, сеанс и cookie

Сервер: облачный 16 ядер х 2,66 ГГЦ / 512 RAM / 10Gb HDD.

Показания скрипта PhpSysInfo.

Результат исполнения команды free совпадает с показаниями PhpSysInfo.

Сервер — Debian 6, установлены nginx и php5-fpm с php-apc и memcached. Больше ничего там не крутится, даже почта — через ssmtp.

Вопрос: это нормально? Что делать? Куда копать? Как уменьшить потребление памяти?

Вопрос задан более трёх лет назад
10824 просмотра

А для чего Вам свободная память? Жалко что ли? Поделится если что, не волнуйтесь. У меня на 190 метрах памяти все забил, и ниче, и с мускулом делится и остальные не страдают. Волноваться стоит не когда память забита и все работает, а когда что-то не работает _потому что_ память забита. Хм. Вы правы, я уже думал об этом. Тем более, что и с бОльшими настройками все летало идеально и никаких проблем не было. Но отсутствие запаса по ОЗУ разве не критично для сервера? Критично когда программы «жадничают», или когда есть программы для которых критично отсутствие памяти (mongo), в остальном это не всегда критично, большинство программ с радостью подвинутся при первой нужде, особенно когда они резервируют память «просто так, на всякий случай». Спасибо большое. Ну а кому верить — команде free или показаниям Вебмина? Может быть, врут оба из-за того, что сервер — «облачный»? 50-60 мегабайт ОЗУ по запасу — приемлемо для того, чтобы быть спокойным? Вот тут уже не скажу ничего =) Точными цифрами не владею. Скажу только то что у меня виртуал со 190 озу. Тоже стоит нгинкс + фпм и мускул. Вся память полностью занята, в своп не лезет, значит всем все хватает. Да и тормозов не обнаруживается… Хотя и нагрузки нет =) Не сочтите за назойливость :) Я Вам уже жутко благодарен, но «полностью забиты» — это совсем полностью или, как и в моем случае, процентов 10 остается свободной памяти? piccy.info/view3/1262143/7bee40ab8b9986fc2df4ea030811426f/
Я ошибся, у меня 160 =) Забито «под чистую», ни капельки не оставило

free memory = wasted memory :D

Пока не начало тормозить или свопиться, заранее беспокоиться не о чем.

Solaris, например, вообще бы забрала всю RAM под дисковый кэш ZFS. Вернув при нужде, по первому требованию, когда кому-то понадобится.

free memory = wasted memory

Отличная фраза. Распечатаю и повешу над кроватью :) Спасибо.

Приду домой, посмотрю в книге, кто автор :) Если мне не изменяет мой склероз, то я когда-то давно~~, когда был молодой и худой, году в 1997,~~ прочел эту фразу у Helen Custer в «Inside Windows NT». Но она там кого-то цитировала. прошу прощения, обещал и прообещался :) беглым взглядом цитату не нашел, а всю книгу внимательно перечитывать некогда. Могу предположить, что каждый воркер имеет в себе весь php-apc кеш, поэтому кушается столько памяти.
Единственная проблема, которая может быть — php-fpm memory leak, но если после рестарта php-fpm он кушает примерно столько же памяти, сколько и до рестарта, значит утечек скорее всего нет
Ну и как вам уже сказали, волноваться надо, когда используется своп

Разобрался, в чем было дело: слишком сильно был раздут кэш при малом количестве рабочих процессов nginx и php-fpm, плюс была включена функция масштабирования нагрузки в свойствах сервера. Масштабирование отключил, количество рабочих процессов nginx и php-fpm значительно увеличил, кэш незначительно уменьшил — память освободилась до 150-200 мегабайт в зависимости от нагрузки, из них около 100 мегабайт кэша.

Возможно вы уже читали мои предыдущие статьи: здесь, здесь и здесь. С них вы должны были понять, что мой блог, да и вообще практически все другие сайты уже несколько месяцев крутятся на виртуальном сервере и мне все очень и очень нравится. Но так было не всегда. Сразу как только я перешел на виртуальный сервер с виртуального хостинга, оказалось, что без оптимизации сервер ещё хуже работает, чем хостинг. При нагрузочном тестировании, сайт подал при 50 посетителях онлайн, что мне очень не нравилось. Конечно же, можно было за $100 нанять системного администратора и он бы все сделал, но мне таких денег было жалко, да и самому интересно.

Вообщем, в первую очередь, я отказался от apache в пользу NGINX + PHP-FPM. Там в принципе ничего сложного не было, только нужно было прописать правильные данные у конфигурационных файлах для конкретных CMS (ссылки выше). Вообщем, все это я сделал и заметил, что сайты чертовски быстро грузятся. Но, радость моя была не долгой. Где-то за сутки, я обнаружил, что вся моя оперативная память (2 ГБ) забита и сайты перестали работать. Конечно же, я думал, что у меня слабая виртуалка, поэтому создал SWAP-файл. Но дело оказалось вовсе не в малой мощности сервера, а в том, что PHP-FPM породил множество дочерних процессов которые и съели всю свободную память.

Полазив по интернете, я нашел очень интересную статью по настройке php-fmp (сейчас к сожалению уже и не помню ссылки).

Вот как у меня сейчас выглядит глобальный файл конфигурации: /etc/php-fpm.conf

А вот конфигурация пула: /etc/pfp-fpm.d/blog.conf

Вот собственно на этой конфигурации уже несколько месяцев работает мой виртуальный сервер, при этом потребляя не более 900 mb. Что-то объяснить с примеров выше я не смогу, так как не являюсь системным администратором, просто по воли судьбы пришлось решать проблемы, которые должен решать сис админ. А эта статья, возможно никому пользы не принесет, но в случае необходимости я буду знать, что у меня есть пример, откуда можно взять информацию.

Добавить в избранное

Главное меню » Операционная система Linux » Настройка PHP-FPM для повышения производительности + Low Memory

(1 оценок, среднее: 5,00 из 5)

P HP-FPM имеет конфигурацию по умолчанию, которая использует больше памяти, чем это необходимо. Она имеет запасные PHP-FPM процессы, готовые запускаться, занимая память в случае, если есть PHP код в обработки. Хотя это и не проблема, если у вас есть тонны оперативной памяти, это может быть проблемой для низкой VPS RAM и если вы используете агрессивное кэширование страниц, то это память используется без необходимости, которая может быть использована для MariaDB (MySQL) или для других важных процессов. Это руководство объясняет, как настроить конфигурацию Nginx с PHP-FPM работающем на PHP 7.0, чтобы использовать как можно меньше оперативной памяти, как это возможно.

Настройка PHP-FPM для повышения производительности + Low Memory

Откройте файл конфигурации PHP-FPM для PHP 7.0.

Настройте следующие значения, как показано ниже, обратите внимание на ; перед pm.start_servers , pm.min_spare_servers и pm.max_spare_servers .

pm = ondemand означает, что дочерние процессы в PHP-FPM будут порождаться только при необходимости

pm.max_children это максимальное количество дочерних процессов, которые будут разрешены, 50 является достаточно либеральным, но если вы видите в своем архиве журналов что количество дочерних процессов превысило максимальное значение, то необходимо увеличить это значение

pm.process_idle_timeout убивает дочерние процессы после того, как они бездействовали в течение 10 секунд

pm.max_requests устанавливает максимальное количество запросов PHP для каждого дочернего процесса

Проверьте правильность вашего синтаксиса конфигурации PHP-FPM

Вы должны увидеть, что конфигурация действует

Теперь вы можете перезапустить php7.0-FPM

Вы можете увидеть, что объем оперативной памяти используется значительно меньше.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте также: