Php fpm listen backlog

PHP-FPM. НАСТРОЙКА И ТЮНИНГ

php-fpm – PHP FastCGI менеджер процессов. Используется в связке с nginx + php. По моему мнению лучшая связка для веб-сайтов.

Цель

Разобраться в параметрах конфигурации, и решить проблему, которая возникла на продакшен сервере с чрезмерным потреблением оперативной памяти. Произошло это потому, что php-fpm породил множество дочерних процессов, которые с радостью съели память, и, в один прекрасный момент, когда еще запустился парсер, OOM-killer положил мою машину. Причем ночью. На 6 часов. Почему она именно зашатдаунилась, а не ребутнулась – это другой вопрос, но неприятный впечатлений была масса.

Конфигурация и термины

/etc/php-fpm.conf – глобальная конфигурация

/etc/php-fpm.d/* – конфигурация пулов

Pool – это группа процессов, выделенная для обработки запросов, поступающих на определённый порт или Unix-сокет. В PHP-FPM возможно использовать отдельные пулы для каждого сайта и точно распределять ресурсы, а также использовать разных пользователей и разные группы для каждого пула.

Если пулы работают от имени одного и того же пользователя, разделение приложений по пулам позволяет предотвратить ситуацию, когда высоконагруженное приложение постоянно держит занятыми процессы-обработчики, не давая таким образом нормально работать лёгким интерактивным приложениям.

Для каждого из пулов можно задавать разные настройки PHP. Причем эти настройки будут иметь приоритет выше, чем те, что в php.ini либо те, которые могут задаваться напрямую из php-скриптов.

Конфигурация и параметры

Итак, начнем с глобального конфига:

Теперь можно рассмотреть конфигурацию пула (для примера /etc/pfp-fpm.d/blog.conf):

Также, отредактируем php.ini файл, указав:

О подсчетах параметров:

Остается закономерный вопрос: а как же выбрать комфортные параметры для сайта? С дефолтным конфигом сделаем следующее:
1. Предположим, что у нас есть VDS с 512 Mb оперативной памяти, из которой 200 Mb мы можем выделить под PHP-FPM.
2. Возьмем “тяжелые” страницы сайта и откроем их (желательно почти параллельно) в том колличестве, сколько потенциально их может быть открыто параллельно в пиковые нагрузки (при этом количество страниц возьмем с небольшой дельтой в большую сторону)
3. Смотрим через htop количество памяти, которое забрали под себя процессы php-fpm. Добустим это 20 Mb на каждый. Тогда добавив дельту в 10%, будем считать что это 22 Mb.
4. Считаем значение для параметра pm.max_children:
200 / 22 = 9.09

Приемлемым значением pm.max_children будет 9. Это значение основано на среднем значении и возможно далее его необходимо будет изменить, когда вы заметите длительное время использования памяти процессом. После быстрого тестирования несложно выбрать значения pm.start_servers, pm.min_spare_servers и pm.max_spare_servers. Максимальное количество запросов на процесс по умолчанию не ограничено, но хорошо бы установить какое-нибудь небольшое значение, например 200, и избежать проблем с памятью. Такого вида настройка может обрабатывать большое количество запросов, даже если значение параметра невелико.

В итоге, получаем примерно такой блок конфигурации:

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

Настройка и highload-тюнинг php-fpm Попробуем определить каким образом можно повысить производительность сервера приложений на базе php-fpm, а также сформировать чек-лист для проверки конфигурации fpm…

Cлучайные числа с плавающей точкой в PHP Стандартные библиотеки PHP умеют генерировать только целые случайные числа. Однако, возникают задачи где нужно не целое рандомное число с максимально…

Особенности http_build_query в PHP Казалось бы http_build_query — простая функция, однако, имеет некоторые особенности. Нельзя однозначно сказать что это баг, скорее просто недокументированная фича,…

Источник

Советы по настройке и оптимизации Nginx и PHP-FPM

Thank you for reading this post, don’t forget to subscribe!

Определить Nginx worker_processes и worker_connections

Настрой­ки по умол­ча­нию хоро­ши, но их сто­ит немно­го опти­ми­зи­ро­вать: max_clients = worker_processes * worker_connections .

Базо­вые настрой­ки Nginx могут обра­ба­ты­вать сот­ни одно­вре­мен­ных соединений:

Обыч­но 1000 одно­вре­мен­ных соеди­не­ний на один сер­вер это хоро­шо, но порою дру­гие части, напри­мер жест­кий диск могут ока­зать­ся мед­лен­ны­ми и это при­ве­дет к тому, что Nginx будет забло­ки­ро­ван на опе­ра­ции вво­да-выво­да (I/O). Что­бы избе­жать бло­ки­ров­ки исполь­зуй­те, напри­мер, сле­ду­ю­щие настрой­ки: одни worker_process на ядро процессора :

Worker Processes

Что­бы опре­де­лить сколь­ко ядер име­ет ваш про­цес­сор, введите:

В дан­ном слу­чае у меня четы­ре ядра, поэто­му окон­ча­тель­ный пара­мерт worker_processes уста­нав­ли­ва­ем как 4:

Worker Connections

Лич­но я при­дер­жи­ва­юсь 1024 соеди­не­ний на один вор­кер, пото­му что у меня нет ника­ких осно­ва­ний для повы­ше­ния это­го зна­че­ния. Но если напри­мер 4096 соеди­не­ний в секун­ду не хва­та­ет, то мож­но попро­бо­вать удво­ить 2048 соеди­не­ний на процесс.

Окон­ча­тель­ные настрой­ки выгля­дят седу­ю­щим образом:

Скрыть токены Nginx / Скрыть номер версии Nginx

Это хоро­шо из сооб­ра­же­ний без­опас­но­сти — скрыть токе­ны Nginx и скрыть номер вер­сии Nginx, тем более если вы исполь­зу­е­те уста­рев­шую вер­сию Nginx. Это очень лег­ко сде­лать — доста­точ­но доба­вить в сек­цию http/server/location фай­ла кон­фи­гу­ра­ции сле­ду­ю­щую строку:

Ограничение на размер передаваемых данных сервером Nginx

Если вы хоти­те раз­ре­шить поль­зо­ва­те­лям загру­жать фай­лы, то вы долж­ны уве­ли­чить раз­мер сооб­ще­ния. Это может быть сде­ла­но с помо­щью зна­че­ния client_max_body_size , кото­рое нахо­дит­ся в сек­ции http/server/location фай­ла кон­фи­гу­ра­ции. По умол­ча­нию он равен 1 Мб, но его мож­но уве­ли­чить, напри­мер, до 20 Мб, а так­же уве­ли­чить раз­мер буфера:

Если вы полу­ча­е­те сооб­ще­ние об ошиб­ке, то вы зна­е­те, что client_max_body_size слиш­ком мало:

Управление кешем для статических файлов

Кэш бра­у­зе­ра сохра­нит ресур­сы и про­пуск­ную спо­соб­ность ваше­го сер­ве­ра. Это неслож­ная настрой­ка Nginx поз­во­лит выклю­чить веде­ние логов ( access log и not found log ), и уста­но­вить срок исте­че­ния заго­лов­ка в 360 дней.

Если вы хоти­те более слож­ный заго­лов­ки или дру­гие типы фай­лов, то вы може­те настро­ить их отдельно.

Проксируйте PHP запросы к PHP-FPM

Вы може­те исполь­зо­вать по умол­ча­нию стек tcp/ip или соеди­не­ние через Unix-сокет. Так­же необ­хо­ди­мо уста­но­вить PHP-FPM слу­шать точ­но такой же ip:port или Unix-сокет. Вот очень про­стой при­мер кон­фи­гу­ра­ции (вари­ант с Unix-соке­том закоментирован):

Это дает воз­мож­ность запус­ка PHP-FPM дру­гим сервером.

Предотвращение (запрет) доступа к скрытым файлам

Это очень рас­про­стра­не­но, когда корень сер­ве­ра или дру­гие пуб­лич­ные ката­ло­ги име­ют скры­тые фай­лы, кото­рые начи­на­ют­ся с точ­ки (.) И, как пра­ви­ло, они не пред­на­зна­че­ны для поль­зо­ва­те­лей сай­та. Пуб­лич­ный ката­лог может содер­жать фай­лы систе­мы кон­тро­ля вер­сий: .git , .svn ; фай­лы IDE : .idea ; .htaccess фай­лы. Настрой­ки запе­ща­ют доступ к скры­тым фай­лам и отклю­ча­ют веде­ние логов:

Советы по настройке и оптимизации PHP-FPM

Файлы конфигурации PHP-FPM

Обыч­но кон­фи­гу­ра­ции PHP-FPM рас­по­ло­жен­ны в фай­ле /etc/php-fpm.conf и в ката­ло­ге /etc/php-fpm.d/ . Весь пулл кон­фи­гов расо­пло­жен в дикер­то­рии /etc/php-fpm.d/ . Что­бы это рабо­та­ло, вы долж­ны доба­вить сле­ду­ю­щую стро­ку в php-fpm.conf :

Глобальная конфигурация PHP-FPM

Настрой­ки emergency_restart_threshold , emergency_restart_interval и process_control_timeout по умол­ча­нию выклю­че­ны, но я счи­таю что их сто­ит влю­чить, напри­мер, со сле­ду­ю­щи­ми значениями:

Что это зна­чит? Если 10 дочер­них про­цес­сов PHP-FPM завер­шат­ся с помо­щью SIGSEGV или SIGBUS в тече­нии 1 мину­ты, то PHP-FPM пере­за­гру­зит­ся авто­ма­ти­че­ски. А так­же дочер­ним про­цес­сам уста­нов­лен лимит вре­ме­ни реак­ции в 10 секунд на сиг­нал от мастера.

Конфигурация пулов PHP-FPM

В PHP-FPM воз­мож­но исполь­зо­вать отдень­ные пулы для каж­до­го сай­та и точ­но рас­пре­де­лять ресур­сы, а так­же исполь­зо­вать раз­ных поль­зо­ва­те­лей и раз­ные груп­пы для каж­до­го пула. При­ве­дем при­ме­ры кон­фи­гу­ра­ци трех раз­лич­нх сай­тов (или фак­ти­че­ски три части одно­го сайта):

/etc/php-fpm.d/site.conf
/etc/php-fpm.d/blog.conf
/etc/php-fpm.d/forums.conf

При­ме­ры кон­фи­гу­ра­ции каж­до­го пула:
/etc/php-fpm.d/site.conf

/etc/php-fpm.d/blog.conf

/etc/php-fpm.d/forums.conf

Это про­сто при­ме­ры как настро­ить несколь­ко раз­лич­ных пулов.

Конфигурация менеджера процессов (Pool Process Manager) PHP-FPM

Луч­ший спо­соб исполь­зо­вать мене­джер про­цес­сов PHP-FPM — это дона­ми­че­ское управ­ле­ние про­цес­са­ми, поэто­му PHP-FPM запус­ка­ет про­цес­сы толь­ко при необ­хо­ди­мо­сти. Это почти такой же под­ход как в Nginx с пара­мет­ра­ми worker_processes и worker_connections . Таким обра­зом боль­шие зна­че­ния не обес­пе­чи­ва­ют хоро­ше­го резуль­та­та. Каж­дый про­цесс ест опре­делн­ное коли­че­ство памя­ти и, конеч­но, если у сай­та очень боль­шой тра­фик и мно­го опе­ра­тив­ной памя­ти на сер­ве­ре, то высо­кие зна­че­ния — это пра­виль­ный выбор. Но такие сер­ве­ры как VPS обыч­но име­ют огра­ни­чен­ное коли­че­ство памя­ти: 256 Мб, 512 Мб, 1024 Мб. Тако­го неболь­шо­го объ­е­ма ОЗУ доста­точ­но даже для очень боль­шо­го тра­фи­ка (даже десят­ки запро­сов в секун­ду), если эту память исполь­зо­вать с умом.

Про­ве­рим сколь­ко про­цес­сов PHP-FPM поз­во­лит лег­ко справ­лять­ся сер­ве­ру с нагруз­кой. Сна­ча­ла запу­стим Nginx и PHP-FPM и загру­зим несколь­ко стра­ниц PHP , жела­тель­но самые тяже­лые. Затем про­ве­рим сколь­ко исполь­зу­ет памя­ти про­цесс PHP-FPM — в Linux мож­но вос­поль­зо­вать­ся ути­ли­та­ми top или htop . Пред­по­ло­жим что наш сер­вер име­ет 512 Мб опе­ра­тив­ной памя­ти и 220 Мб может быть исполь­зо­ван­но PHP-FPM , каж­дый про­цесс исполь­зу­ет 24 Мб опе­ра­тич­ной памя­ти (неко­то­рые CMS с пла­ги­на­ми могут лег­ко кушать 20-40 Мб на один запрос или даже боль­ше). Затем про­сто вычис­лим знач­ние max_children для сервера:

При­ем­ле­мым знач­ни­ем pm.max_children будет 9. Это знач­ние осно­ван­но на сред­нем зна­че­нии и воз­мож­но далее его необ­хо­ди­мо будет изме­нить, когда вы заме­ти­те дли­тель­ное вре­мя исполь­зо­ва­ния памя­ти про­цес­сом. После быст­ро­го тести­ро­ва­ния неслож­но выбрать знач­ния pm.start_servers value , pm.min_spare_servers и pm.max_spare_servers .

Окон­ча­тель­ная кон­фи­гу­ра­ция наше­го при­ме­ра может выгля­деть сле­ду­ю­щим образом:

Мак­си­ма­ло­ное коли­че­ство запро­сов на про­цесс по умол­ча­нию не огра­ни­че­но, но хоро­шо бы уста­но­вить какое-нибудь неболь­шое зна­че­ние, напри­мер 200, и избе­жать про­блем с памя­тью. Тако­го вида настро­ка может обра­ба­ры­вать боль­шое коли­че­ство запро­сов, даже если зна­че­ние пара­мет­ра невелико.

Подроб­ный раз­бор пара­мет­ров кон­фи­гу­ра­ци­он­ных файлов:

Источник