Мануал по настройке Nginx+php-fpm

n0n4m3

Эксперт
Сообщения
321
Реакции
81
Сначала нам нужно взглянуть на файл конфигурации по умолчанию для PHP-FPM. Вы хотите найти раздел, который выглядит следующим образом:
Код:
; Выберите, как менеджер процессов будет контролировать количество дочерних процессов.
; Возможные значения:
; static - фиксированное число (pm.max_children) дочерних процессов;
; динамический - число дочерних процессов устанавливается динамически на основе
; следующие директивы:
; pm.max_children - максимальное количество детей, которые могут
; быть живым в то же время.
; pm.start_servers - количество детей, созданных при запуске.
; pm.min_spare_servers - минимальное количество детей в режиме ожидания
; состояние (ожидает обработки). Если номер
; «холостых» процессов меньше, чем это
; номер, то некоторые дети будут созданы.
; pm.max_spare_servers - максимальное количество детей в «простое»
; состояние (ожидает обработки). Если номер
; «холостых» процессов больше, чем это
; номер, тогда некоторые дети будут убиты.
; Примечание: это значение обязательно.

pm = динамический
; Количество дочерних процессов, которые будут созданы, когда pm установлен на «static» и
; максимальное количество дочерних процессов, которые будут созданы, когда pm установлен на 'dynamic'.
; Это значение устанавливает ограничение на количество одновременных запросов, которые будут
; служил. Эквивалентно директиве ApacheMaxClients с mpm_prefork.
; Эквивалент переменной среды PHP_FCGI_CHILDREN в исходном PHP
; CGI.
; Примечание. Используется, когда pm имеет значение «static» или «dynamic».
; Примечание: это значение обязательно.
pm.max_children = 60

; Количество дочерних процессов, созданных при запуске.
; Примечание. Используется только в том случае, если для pm установлено значение «dynamic».
; Значение по умолчанию: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
pm.start_servers = 20

; Желаемое минимальное количество незанятых серверных процессов.
; Примечание. Используется только в том случае, если для pm установлено значение «dynamic».
; Примечание. Обязательно, если для параметра pm установлено значение «dynamic».
pm.min_spare_servers = 20

; Желаемое максимальное количество незанятых серверных процессов.
; Примечание. Используется только в том случае, если для pm установлено значение «dynamic».
; Примечание. Обязательно, если для параметра pm установлено значение «dynamic».
pm.max_spare_servers = 35

; Количество запросов, которые каждый дочерний процесс должен выполнить перед повторным вызовом.
; Это может быть полезно для обхода утечек памяти в сторонних библиотеках. За
; бесконечная обработка запроса указывает '0'. Эквивалент PHP_FCGI_MAX_REQUESTS.
; Значение по умолчанию: 0
pm.max_requests = 500
Решение
Код:
pm = dynamic
pm.max_children = 30
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
Теперь разбор полетов!
Код:
pm.max_children = необходимо вычислить сколько памяти занимает один процесс, потом разделить тот объем памяти который вы хотите выделить для php5-fpm, на объем одного процессора, получите количество pm.max_children (наример 10000мб/50мб=200)
pm.min_spare_servers = этот параметр начать с количество ядер процессора умножить на 2 (пример 4 ядра * 2 = 8)
pm.max_spare_servers = этот параметр количество ядер процессора * 4 (пример 4 *4 = 16)
pm.start_servers = этот параметр вычисляется по формуле (pm.min_spare_servers+pm.max_spare_servers)/2 (пример (8+16)/2=12)
Итого на выходе получаем примерно конфигурацию для 4 ядерного процессора 10гб памяти (выделенные только под PHP5-FPM, возможно у вас 16Гб общей)
pm.max_children = 200
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 16
Все настройки индивидуально под мой сервер.

В Nginx нужно вставлять правила на урл после
Код:
location / {
иначе правила работать не будут
Пример:
Код:
location / {
    rewrite ^/page/([0-9]+)(/?)$ /index.php?cstart=$1 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/page,([0-9]+),([0-9]+),(.*).html$" /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&cstart=$5&news_name=$6&seourl=$6 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/page,([0-9]+),(.*).html$" /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&news_name=$5&seourl=$5 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/print:page,([0-9]+),(.*).html$" /index.php?mod=print&subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&news_name=$5&seourl=$5 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*).html$" /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_name=$4&seourl=$4 last;
    rewrite ^/([^.]+)/page,([0-9]+),([0-9]+),([0-9]+)-(.*).html$ /index.php?newsid=$4&news_page=$2&cstart=$3&seourl=$5&seocat=$1 last;
    rewrite ^/([^.]+)/page,([0-9]+),([0-9]+)-(.*).html$ /index.php?newsid=$3&news_page=$2&seourl=$4&seocat=$1 last;
    rewrite ^/([^.]+)/print:page,([0-9]+),([0-9]+)-(.*).html$ /index.php?mod=print&news_page=$2&newsid=$3&seourl=$4&seocat=$1 last;
    rewrite ^/([^.]+)/([0-9]+)-(.*).html$ /index.php?newsid=$2&seourl=$3&seocat=$1 last;
    rewrite ^/page,([0-9]+),([0-9]+),([0-9]+)-(.*).html$ /index.php?newsid=$3&news_page=$1&cstart=$2&seourl=$4 last;
    rewrite ^/page,([0-9]+),([0-9]+)-(.*).html$ /index.php?newsid=$2&news_page=$1&seourl=$3 last;
    rewrite ^/print:page,([0-9]+),([0-9]+)-(.*).html$ /index.php?mod=print&news_page=$1&newsid=$2&seourl=$3 last;
    rewrite ^/([0-9]+)-(.*).html$ /index.php?newsid=$1&seourl=$2 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})(/?)+$" /index.php?year=$1&month=$2&day=$3 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/page/([0-9]+)(/?)+$" /index.php?year=$1&month=$2&day=$3&cstart=$4 last;
    rewrite "^/([0-9]{4})/([0-9]{2})(/?)+$" /index.php?year=$1&month=$2 last;
    rewrite "^/([0-9]{4})/([0-9]{2})/page/([0-9]+)(/?)+$" /index.php?year=$1&month=$2&cstart=$3 last;
    rewrite "^/([0-9]{4})(/?)+$" /index.php?year=$1 last;
    rewrite "^/([0-9]{4})/page/([0-9]+)(/?)+$" /index.php?year=$1&cstart=$2 last;
    rewrite ^/tags/([^/]*)(/?)+$ /index.php?do=tags&tag=$1 last;
Оптимизация Nginx Centos 7
Код:
/etc/nginx/nginx.conf
Файл настроек обычно выглядит так:
Код:
user www-data;
worker_processes 1;

events {
    worker_connections 1024;
}

http {
    ...
}
Вся конфигурация
Код:
worker_processes  auto;
events {
    use epoll;
    worker_connections 1024;
    multi_accept on;
}
http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log crit;

    keepalive_timeout  30;
    keepalive_requests 100;

    client_max_body_size  1m;
    client_body_timeout 10;
    reset_timedout_connection on;
    send_timeout 2;
    sendfile on;
    tcp_nodelay on;
    tcp_nopush on;

    gzip on;
    gzip_disable "msie6";
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}
Самое важное
Самым большим эффектом на посетителей окажет включение сжатия gzip.
 

ovozz

Эксперт
Клиент
Сообщения
300
Реакции
86
было бы круто еще узнать, что такое PHP-FPM, чем он отличается от apache и как правильно перевести сайты на него
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@ovozz,http://php.net/manual/ru/install.fpm.php

PHP-FPM - это разновидность SAPI для PHP. Чтобы понять что это такое стоит рассказать о понятии SAPI.

FPM
SAPI, он же Server API. В php есть несколько таких API для разных вариантов его работы:

  • CLI SAPI - в качестве консольной команды `php` для запуска наших кронов и других cli-программ (Command Line Interface)
  • apxs2 SAPI - в качестве модуля к apache2
  • CGI SAPI - в качестве запускаемого на каждом запросе CGI (сейчас так почти никто не делает)
  • FPM SAPI - Fast Process Manager написанный для PHP разработчиками из комании Badoo и теперь поддерживаемый сообществом
Работа с FPM отличается от работы с Apache в первую очередь тем, что FPM - это только PHP. Это не веб-сервер, не что-то умное. Это наоборот - максимально простой, легкий и быстрый менеджер процессов для PHP. В отличие от апача он даже не используется http-протокол, а работает со специальным fastcgi-протоколом. В первую очередь FPM быстрее обрабатывает запросы благодаря его легковесности и простоте.

Во вторую очередь FPM действительно умный менеджер процессов. Он контролирует количество работающих PHP-процессов, частоту их перезапуска для борьбы с утечками памяти (да, модули php как и всегда текут) и прочие простые вещи, необходимые для контроля сервера.

Нужно помнить, что независимо от того, какое SAPI вы используете, будь то модуль Apache, CGI или PHP-FPM - это не отнимает ни каких особенностей php. А первая его особенность:

  • Один процесс одновременно обрабатывает один запрос. Это абсолютно так же свойственно для PHP-FPM, как и для Apache.
  • Количество процессов определяет сколько одновременно может "висеть" запросов в обработке.
  • Точно также, как и Apache, FPM подвержен DoS-атакам путем "длительных запросов". Допустим у Вас на сервере работает не более 50и процессов PHP-FPM, а это значит, что если 50 пользователей одновременно начнут делать upload файла (пусть даже небольшого, но главное чтобы они делали это медленно) - пятьдесят первый пользователь получит ошибку 504, т.к. FPM не возьмет его запрос на обработку, пока не разберется с теми что у него уже есть.
NGINX
Nginx - это разработанный Игорем Сысоевым http-proxy-сервер (он сам чаще называет его proxy-сервером, чем web-сервером). Это и есть его основное отличие от Apache (обычно к nginx приходят те кто испытывает проблемы с Apache). Благодаря тому что Nginx, сам не выполняет никакой тяжелой работы - Игорь смог заложить в него прекрасную асинхронную событийную архитектуру.

Благодаря этой архитектуре nginx на порядки быстрее обрабатывает запросы, чем любой другой сервер и благодаря ей же потребляет при этом сильно меньше ресурсов. Как это происходит?

Один рабочий процесс nginx - обрабатывает не один запрос пользователя (как apache), а тысячи этих запросов. Ввиду того, что nginx - это proxy-сервер, для него не составляет никакого труда получить запрос пользователя, отправить его на backend (например php-fpm), а пока бакенд занят трудом - обрабатывать остальные запросы пользователей, когда FPM ответит Nginx-у о том что тот самый первый запрос обработан и отдаст ответ, nginx передаст ответ назад пользователю.

Nginx работает как конвеер - он просто быстро перекладывает запросы и ответы между backend и пользователями.

В эту схему отлично вписалась асинхронная работа со статическими файлами. Благодаря тому что в современном мире с файлами можно работать почти так же асинхронно, как и с backend - Nginx отлично разделяет работу на две части - статику отдает с диска, динамику обрабатывает в PHP-FPM.

В чем выигрыш?
Возьмем тот же Apache (prefork или itk). Мы выставили у него максимальное количество рабочих процессов равное 35. Что это значит? Это значит что мы сможем одновременно обработать только 35 запросов пользователей и это не важно - запрос это за статикой или за динамикой. 35 всего.

У вас на странице 100 картинок+js+css-ок? Значит большая их часть будет висеть в очереди внутри сервера Apache и ждать когда пользователь получит предыдущие 35 ответов.

В случае с Nginx + PHP-FPM важнее всего количество процессов PHP-FPM. Мы можем поставить его таким же равным тридцати пяти. Что это значит? Это значит что мы можем одновременно обрабатывать 35 запросов к динамике, запросы же к статике nginx разгребет своими силами в количестве 3000+ одновременных почти на любой слабой VPS.

Расход оперативной памяти при использовании Nginx+PHP-FPM меньше чем на "голом" Apache, при равном количестве процессов (FPM и Apache). Скорость обработки запросов выше.

На расход CPU внутри PHP замена Apache на FPM никак не скажется. CPU в первую очередь кушает Ваш PHP-код, а пока его никто не оптимизирует - работать быстрее и экономичнее он не начнет.

Итог
  • Все проблемы PHP (процесс на запрос, не оптимальный код самого проекта) никуда не деваются.
  • Появляется возможность перелопачивать тонны запросов за статикой, которой нет в Apache.
  • Вы экономите оперативную память, что сказывается на цене оборудования или VPS.
  • Появляется море приятного функционала самого Nginx.
  • Пропадает возможность использовать htaccess, но честно скажу - конфигурация nginx куда более простая и понятная, чем htaccess.
 

Coilfenix

Ветеран
Сообщения
84
Реакции
30
@n0n4m3, советую указывать уровень сжатия gzip
Код:
gzip_comp_level 5;
И что у вас в
Код:
include /etc/nginx/mime.types;
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@n0n4m3, советую указывать уровень сжатия gzip
Код:
gzip_comp_level 5;
И что у вас в
Код:
include /etc/nginx/mime.types;
есть норм сервер то можно и 9 ставить.
include /etc/nginx/mime.types;
По стандарту с коробки все идет.
У меня свое!
 

Coilfenix

Ветеран
Сообщения
84
Реакции
30
@n0n4m3, что именно у вас там. Иначе смею предположить, что у вас крайне некорректно настроены конфиги, в принципе, как и в вашей другой теме...
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@Coilfenix, у меня вопрос такой файл mime.types идет по дефолту в nginx?
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
@n0n4m3, спасибо за отлично расписанную статью. Вы круто постарались, выложив свой мануал и объяснив все по полочкам. Еще не доводилось встречать переведенный конфиг NGINX на русский)))

Если говорить простым языком, то для проектов, у которых есть трафик от 4к в сутки (сужу по своему опыту, все зависит от движка и его оптимизации), для проектов, у которых на диске есть физические файлы для скачивания (например, mp3) лучше подойдет NGINX. Его корректная настройка исключит "зависание" проекта, особенно в пиковые нагрузки по трафику, когда все все слушают и качают. А это напрямую отображается на трафике.
Например, для понимания, у меня на чистом LEMP (Linux+NGINX+Mysql+PhpMyadmin) на VPS с 4GB ОЗУ, 4CPU при пиковых загрузках в 300 уников в час проект кушал ~490 Мб ОЗУ и ~по 20-30% мощности от каждого из ядра. Тут ключевое слово - корректная настройка сервера.

Если кому-то интересно разобраться подробней, рекомендую изучить эти видеоуроки. Кому интересно, пишите в личку, подскажу где можно достать классные курсы по администрированию GNU/LINUX с самого нуля с уклоном в WEB (не реклама). Подойдут для тех, кто что-то умеет в консоли, но не может структурировать информацию.

Я например, рад переходу с Apache на NGINX. Сервер проще в понимании и более гибок в настройках. Сервер модульный, и не требует полной перезагрузки после подгрузки модуля. Да и работать с ним приятней. Опять же, это моё субъективное мнение.
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
Вот еще, знакомый системный администратор рекомендовал сначала изучить мануал по NGINX http://nginx.org/ru/
Еще есть книга "Администрирование сервера NGINX" (Дмитрий Айвалиотис), которая по сути переписала этот мануал на более человекопонятный язык. Скажу честно, что до ее прочтения еще руки не дотянулись, но во вступлении написано, что книга структурирована таким образом, что не требует полного изучения, а может юзаться как справочник (пополнение пробелов в знаниях). Так что всем рекомендую. Здесь книгу выкладывать не буду, но загуглите, в свободном доступе есть pdf вариант.
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@Pingvi, мануал староват уже! - теперь на 1гб оперативки летает :)
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
Настройка PHP-FPM: используем pm static для максимальной производительности

Неотредактированная версия статьи была изначально опубликована на haydenjames.io и публикуется здесь с разрешения ее автора.


Я в двух словах расскажу, как лучше всего настроить PHP-FPM, чтобы увеличить пропускную способность, снизить задержку и более стабильно использовать процессорные ресурсы и память. По умолчанию строка PM (process manager, менеджер процессов) в PHP-FPM имеет значение dynamic, а если у вас не хватает памяти, то лучше установить ondemand. Давайте сравним 2 варианта управления на основе документации php.net и посмотрим, чем от них отличается мой любимый static pm для большого объема трафика:


pm = dynamic — количество дочерних процессов настраивается динамически на основе следующих директив: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — процессы создаются по требованию (в отличие от динамического создания, когда pm.start_servers запускаются при запуске сервиса).
pm = static — количество дочерних процессов фиксировано и указывается параметром pm.max_children.

Подробности см. в полном списке глобальных директив php-fpm.conf.


Сходства менеджера процесса PHP-FPM с регулятором частоты процессора

Это может показаться оффтопом, но я собираюсь связать это с темой настройки PHP-FPM. У кого хоть раз не тормозил процессор — на ноутбуке, виртуальной машине или выделенном сервере. Помните масштабирование частоты процессора? Эти параметры, доступные для nix и Windows, могут повысить производительность и скорость отклика системы, если изменить параметр регулятора процессора с ondemand на performance*. На этот раз давайте сравним описания и посмотрим на сходства:


Governor = ondemand — динамическое масштабирование частоты процессора в зависимости от текущей нагрузки. Резко переходит на максимальную частоту, а затем снижает ее, когда увеличиваются периоды простоя.
Governor = conservative = динамическое масштабирование частоты в зависимости от текущей нагрузки. Увеличивает и уменьшает частоту плавнее, чем ondemand.
Governor = performance — частота всегда максимальная.


Подробности см. в полном списке параметров регулятора частоты процессора.


Видите сходство? Я хотел показать это сравнение, чтобы убедить вас, что лучше всего использовать pm static для PHP-FPM.


Для регулятора процессора параметр performance помогает безопасно увеличить производительность, потому что она почти полностью зависит от лимита процессора сервера. Кроме этого, конечно, есть еще такие факторы, как температура, заряд аккумулятора (в ноутбуке) и другие побочные эффекты постоянной работы процессора на 100%. Настройка performance обеспечивает самую быструю работу процессора. Почитайте, например, о параметре force_turbo в Raspberry Pi, с которым панель RPi будет использовать регулятор performance, где улучшение производительности будет заметнее из-за низкой тактовой частоты ЦП.


Использование pm static для достижения максимальной производительности сервера

Параметр PHP-FPM pm static во многом зависит от свободной памяти на сервере. Если памяти мало, лучше выбрать ondemand или dynamic. С другой стороны, если у вас есть память, можно избежать лишних издержек менеджера процесса PHP, установив pm static на максимальную емкость сервера. Другими словами, если все хорошо подсчитать, нужно установить pm.static на максимальный объем процессов PHP-FPM, которые могут выполняться, не создавая проблем с нехваткой памяти или кэша. Но не так высоко, чтобы перегрузить процессоры и накопить кучу операций PHP-FPM, ожидающих выполнения.





На скриншоте выше у сервера установлено pm = static и pm.max_children = 100, и это занимает примерно 10 ГБ из имеющихся 32. Обратите внимание на выделенные столбцы, тут и так все понятно. На этом скриншоте было примерно 200 активных пользователей (более 60 секунд) в Google Analytics. На этом уровне примерно 70% дочерних процессов PHP-FPM все еще бездействуют. Это значит, что PHP-FPM всегда установлен на максимальный объем ресурсов сервера независимо от текущего трафика. Простаивающий процесс ждет пиков трафика и реагирует моментально. Вам не приходится ждать, пока pm создаст дочерние процессы, а потом завершит их, когда истечет период pm.process_idle_timeout. Я установил очень большое значение для pm.max_requests, потому что это рабочий сервер без утечек памяти в PHP. Вы можете установить pm.max_requests = 0 со static, если полностью уверены в имеющихся и будущих скриптах PHP. Но лучше перезапускать скрипты со временем. Установите большое число запросов, ведь мы хотим избежать лишних издержек pm. Например, хотя бы pm.max_requests = 1000 — в зависимости от количества pm.max_children и числа запросов в секунду.


На скриншоте показана команда Linux top, фильтрованная по u (user) и имени пользователя PHP-FPM. Показано только первые 50 или около того процессов (точно не считал), но, по сути, top показывает топ статистики, которая помещается в окно терминала. В этом случае с сортировкой по % ЦП (%CPU). Чтобы посмотреть все 100 процессов PHP-FPM, выполните команду:


top -bn1 | grep php-fpm

Когда использовать pm ondemand и dynamic

Если использовать pm dynamic, возникают подобные ошибки:


WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Попробуйте изменить параметр, ошибка никуда не денется, как описывается в этом посте на Serverfault. В этом случае значение pm.min было слишком маленьким, а раз веб-трафик сильно меняется и у него есть высокие пики и глубокие спады, сложно адекватно настроить pm dynamic. Обычно при этом используется pm ondemand, как советуют в том же посте. Но это еще хуже, ведь ondemand завершает бездействующие процессы до нуля, когда трафика мало или нет вообще, и в итоге вы все равно будете мучиться с издержками при изменении трафика. Если, конечно, вы не установили огромное время ожидания. И тогда лучше уж использовать pm.static + высокое число pm.max_requests.


PM dynamic и особенно ondemand могут пригодиться, если у вас несколько пулов PHP-FPM. Например, вы размещаете несколько аккаунтов cPanel или несколько веб-сайтов в разных пулах. У меня есть сервер, где, допустим, 100+ аккаунтов cpanel и примерно 200 доменов, и pm.static или даже dynamic меня бы не спас. Тут нужен только ondemand, ведь больше двух третей веб-сайтов получают мало трафика или вообще никакого, а с ondemand все дочерние процессы отвалятся, что сэкономит нам уйму памяти! К счастью, разработчики cPanel это заметили и установили значение по умолчанию ondemand. Раньше, когда значением по умолчанию был dynamic, PHP-FPM вообще не подходил для нагруженных общих серверов. Многие использовали suPHP, потому что pm dynamic потреблял память даже при бездействующих пулах и аккаунтах cPanel PHP-FPM. Скорее всего, при хорошем трафике вы не будете размещаться на сервере с большим числом пулов PHP-FPM (общий хостинг).


Заключение

Если вы используете PHP-FPM и трафик у вас серьезный, менеджеры процессов ondemand и dynamic для PHP-FPM будут ограничивать пропускную способность из-за присущих им издержек. Изучите свою систему и настройте процессы PHP-FPM в соответствии с максимальной емкостью сервера. Сначала задайте pm.max_children в зависимости от максимального использования pm dynamic или ondemand, а затем увеличьте это значение до уровня, где память и процессор будут работать без чрезмерной перегрузки. Вы заметите, что с pm static, раз у вас все хранится в памяти, пики трафика со временем будут вызывать меньше пиков для процессора, а средние значения нагрузки сервера и процессора выровняются. Средний размер процесса PHP-FPM зависит от веб-сервера и требует настройки вручную, поэтому более автоматизированные менеджеры процессов — dynamic и ondemand — более популярны. Надеюсь, статья была полезной.


UPD Добавлена диаграмма бенчмарка ab. Если процессы PHP-FPM находятся в памяти, производительность увеличивается за счет потребления памяти, где они сидят и ждут. Найдите для себя оптимальный вариант.


 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
При таком раскладе сервер даже с 512 оперативки летает :)

Также добавлю если установить php 8 и включить JIT посмотрите как летает сайт

ПРОВЕРЕНО!

Мануал обновить полностью не могу так как не могу редактировать первое сообщение!
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
Херасе. надо будет затестить :unsure: Главное, сервер не увалить пока буду тестить))
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
При таком раскладе сервер даже с 512 оперативки летает :)

Также добавлю если установить php 8 и включить JIT посмотрите как летает сайт

ПРОВЕРЕНО!

Мануал обновить полностью не могу так как не могу редактировать первое сообщение!
А у вас траф после настройки прыгнул?
 

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@Pingvi, а при чем тут трафф?

трафф как был так и есть растет сайт стал работать быстрее!
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
Я понимаю ваш скепсис. У вас просто не было моей ситуации. У вас сервер нормально работал и стал еще лучше. А у меня когда-то была как раз проблема, описанная выше в статье с "WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children ". И проявлялась она тем, что при заходе на сайт он "дуплил" от 2 до 10 а иногда 15 секунд. Такая борода происходила раз в час-два. И естественно, никто не будет столько ждать, пока откроется сайт. Пользователи просто закрывали вкладку и шли на другие сайты. Даже скрин нашел🤓. На нем видно, что поминутный траф не нулевой (кто-то все-таки дожидался), но и не такой ровный как обычно.

Скриншота с тем, как траф скакнул я не нашел (может и не скринил), но в минуту пользователей стало гораздо больше, может процентов на 30, не считал.

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

n0n4m3

Эксперт
Сообщения
321
Реакции
81
@Pingvi, ну дак вы использовали наверное pm = dynamicно не суть в том что у вас была правильная конфигурация!

Скиньте вашу настройки я скажу вам правильная она или нет!

Или параметры вашего впс чтоб сделать настройку!

Все зависит от правильной настройки ПО!

Чтобы такого не было нужно правильно все настроить!
 

Pingvi

Местный житель
Сообщения
35
Реакции
6
@Pingvi, ну дак вы использовали наверное pm = dynamicно не суть в том что у вас была правильная конфигурация!

Скиньте вашу настройки я скажу вам правильная она или нет!

Или параметры вашего впс чтоб сделать настройку!

Все зависит от правильной настройки ПО!

Чтобы такого не было нужно правильно все настроить!
Да, именно, у меня стояло dynamic. Тогда стояла чистая NGINX с одним проектом. Сейчас перешел на панельку. Поэтому настройки не сохранились. С вами 100% согласен, дело в корректной настройке сервера. Пока на панельке все тьфу-тьфу работает на ура) Но протестить вами описанный выше способ не помешает. Занесу в задачи, когда раскидаю приоритетные)
 
Сверху