Все что вы делаете вы делаете на свой страх и риск. Я могу только рекомендовать и не претендую на 100% решение, многое зависит от вашего окружения и прочих настроек. О которых я могу и не догадываться. Дополнение материалов и исправление ошибок приветствуется.

Немного оптимизации памяти для Nginx

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

Как результат изменил настройки по умолчанию, на данный момент результат радует, потребление памяти сократилось в 4-5 раз, и теперь не висит с десяток процессов, а всего один. Как будет дальше будем уже по мере поступления проверять. И так поехали, первые изменения по оптимизации памяти.

Находим файл /etc/php-fpm.d/www.conf отрываем в любимом редакторе меняем следующие параметры.

Первое что я изменил это настройки менеджера процессов (pm).

По сути это главный процесс (master process), который будет управлять всеми дочерними по определенной логике. Всего доступно 3 схемы управления процессами:

dynamic
static
ondemand

Наиболее простой - это static. Схема его работы заключается в следующем: запустить фиксированное количество дочерних процессов, и поддерживать их в рабочем состоянии. Схема работы не очень эффективна, так как количество запросов и их нагрузка может меняться время от времени, а количество дочерних процессов нет - они всегда занимают определенный объем ОЗУ и не могут обрабатывают пиковые нагрузки в порядке очереди.
dynamic пул позволяет решить эту проблему, он регулирует количество дочерних процессов исходя из значений конфигурационного файла, изменяя их в большую или меньшую сторону, в зависимости от нагрузки. Данный пул больше всего подходит для сервера, в котором необходима быстрая реакция на запрос, работа с пиковой нагрузкой, требуется экономия ресурсов (за счет уменьшения дочерних процессов при простое).
ondemand пул очень похож на static, но он не запускает дочерних процессов при старте главного процесса. Только когда придет первый запрос - будет создан первый дочерний процесс, и по истечении определенного времени ожидания (указанного в конфигурации) он будет уничтожен. Потому он актуален для серверов с ограниченными ресурсами, или той логики которая не требует быстрой реакции.

Я перешел с dynamic на ondemand на данном этапе у меня нет сверх нагрузки, по этому не нужно мне держать процессы в памяти.

В случае если вы решили остаться на dynamic.

Для основного сервера, часто выбирают dynamic пул. Его работа описывается настройками:

pm.max_children - максимальное количество дочерних процессов
pm.start_servers - количество процессов при старте
pm.min_spare_servers - минимальное количество процессов, ожидающих соединения (запросов для обработки)
pm.max_spare_servers - максимальное количество процессов, ожидающих соединения (запросов для обработки)

Для того чтобы корректно установить эти значения, учитываем: сколько памяти в среднем потребляет дочерний процесс, объем доступного ОЗУ в принципе и не забываем помимо этого процесса у нас есть и другое ПО работающее на сервере. 

В свою очередь я немного уменьшил значения по умолчанию, до первого падения.

pm.start_servers - 5
pm.min_spare_servers - 5
pm.max_spare_servers - 15

Ранее я настраивал кэширование, о котором также отдельно напишу.

В одно из статей половину занимало описание почему стоит перейти с TCP на UDS, но это мне не актуально я сразу все делал на Unix-socket

В продолжение темы Открываем доступ к robots.txt в NGINX при HTTPS-only а также Редирект 301 c http на https и с no-www на www

Благодарю вас за вашу поддержку и доверие. Нажмите кнопку "Пожертвовать" и помогите мне продолжать делиться ценными знаниями и информацией с миром. Посетите страницу >> Поддержите проект.

Популярные метки
восстановление bcdedit xerox print monitor HKEY_CURRENT_USER version 0.3.1409 gigabite twain driver профиль пользователя tools WannaCry