Я провел несколько исследований и обнаружил, что это позволяет рассчитать и настроить pm.max_children стоимость
https://myshell.co.uk/blog/2012/07/adjusting-child-processes-for-php-fpm-nginx/
но например:
Если я применяю это:
pm.max_children = Общий объем ОЗУ, выделенный для веб-сервера / Максимальный размер дочернего процесса
Так что в моем случае:
pm.max_children = 5120/80 = 64
Но если я добавлю pm.max_children = 64 в каждом файле конфигурации веб-сайта php-fpm, это означает, что каждый веб-сайт может использовать 64 ребенка процесс Икс размер 1 процесса (например, 40 МБ) = 2560 Мб
И если мы представим, что в то же время все 30 веб-сайтов достигли значения pm.max_children, у нас будет: 2560 Мб (макс. на сайт) x 30 веб-сайты = 76 800 МБ
Я прав?
Si да, это означает, что когда многие веб-сайты размещены на одном сервере, мы должны разделить результат расчета pm.max_children = 5120/80 знак равно 64 по количеству размещенных сайтов (здесь 30).
Итак, 64/30 = 2,1 и pm.max_children = 2 на сайт
Это правильно или нет?
Спасибо
Ваш расчет верен из того, что я понял.
Наличие нескольких веб-сайтов на одном сервере работает только до тех пор, пока не все веб-сайты используют все доступные ресурсы одновременно. Это то, что обычно называют избыточным выделением ресурсов.
Однако я предлагаю не просто рассчитывать pm.max_children около доступной оперативной памяти, но около того, сколько работников действительно необходимо для правильной работы веб-узлов. Начните с чего-то более низкого и следите за php-fpm.log. Если max_children значение достигнуто, вы найдете его в журнале и можете увеличить.
Также убедитесь, что рабочие PHP живут столько, сколько необходимо. Например, следующая конфигурация позволит пулу использовать до 32 рабочих процессов PHP, если будет пачка запросов, но каждый рабочий будет выходить после 3 секунд бездействия и освобождать ценную оперативную память:
pm = ondemand
pm.max_children = 32
pm.process_idle_timeout = 3s
Использовать ondemand диспетчер процессов, если у вас мало ОЗУ. Это немного медленнее, чем dynamic pm, но не тратит оперативную память на неактивные веб-сайты.
Если вы хотите контролировать общее количество процессов PHP, есть параметр, называемый process.max в php-fpm.conf. Я никогда не использовал его, но мне кажется, что вы могли бы использовать его, чтобы гарантировать, что никогда не будет больше определенного количества рабочих, независимо от того, как настроены пулы.
Кстати, очень хорошая идея - использовать отдельные пулы для отдельных веб-сайтов, принадлежащих разным пользователям. Таким образом, у вас не будет проблем с разрешениями пользователей или с данными, кэшируемыми с других веб-сайтов.
Я могу дать вам совет, основываясь только на нашем опыте.
У нас есть только один пул PHP-FPM для совместного использования ресурсов (ЦП и ОЗУ).
Несколько пулов позволяют использовать разные учетные записи пользователей (например, www-data1, www-data2 ...) и могут помочь ограничить доступ. Кроме того, при необходимости вы можете назначить разные значения для потребления ЦП и ОЗУ.
Однако в следующем примере используется только один пул:
; www.conf
;
; set pool management to have a fixed number of php workers
pm = static
; number of php processes (6 processes per CPU core)
pm.max_children = 48
Я рекомендую использовать управление статическим пулом. Это означает, что всегда есть фиксированное количество работников PHP.
; www.conf
;
; redirect worker stdout and stderr into main error log
catch_workers_output = yes
Это может быть полезно, если в вашем приложении возникают ошибки.
; php-fpm.conf
;
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10s
Это базовый мониторинг жизни ваших работающих PHP-воркеров.
Не забудьте перезапустить службу PHP-FPM после этих изменений.