PHP-скрипты внезапно загружаются очень медленно на Apache
. Я проверяю, почему иногда мои PHP-скрипты долго загружаются по сети (>30 секунд)на моем сервере Apache 2.4 Ubuntu с PHP-FPM 7.4 с использованием mpm. _событие. Последние несколько месяцев сервер работал нормально, это начало происходить несколько дней назад, и я ничего не менял. Делал перезагрузку, не помогло.
Я сделал простой test.php. Иногда он загружается нормально (<100 мс), но иногда для загрузки требуется 1 минута:
<?php echo "test\n"; ?>
- Процессор сервера, оперативная память и ввод-вывод в норме (проверено с помощью
htop). - Статические файлы HTML загружаются без задержек.
- Локальный запуск скрипта через консоль SSH выполняется очень быстро.
- Журналы ошибок Apache не показывают ничего необычного.
- Я проверил наличие DDOS-атак, проверив количество подключенных IP-адресов из одной и той же подсети /16, и не нашел ничего странного (, например. >100 подключений).
Как я могу отладить это, чтобы понять, почему это происходит?
Некоторые выходные данные отладки, которые могут помочь:
sudo service php7.4-fpm status
Я думаю, что нашел решение, но все же, если у вас есть какие-либо предложения, пожалуйста, дайте мне знать или опубликуйте другой ответ.
Я проверил /var/log/php7.4-fpm.logи увидел много подобных записей:
[30-сен-2021 03:36:46] ПРЕДУПРЕЖДЕНИЕ:сервер [pool www] достигнут pm.max_children устанавливает (5), рассмотрите возможность его повышения
Итак, я поднял max_childrenдо 15, и, кажется, это помогает.
Причин такого поведения может быть несколько.:
- Если данный веб-сервер обрабатывает запросы из внешней сети, то с увеличением объема трафика могла увеличиваться нагрузка, что приводило к увеличению времени отклика сервера.
- Если ваши скрипты используют обращения к внешним ресурсам, то в этом случае время отклика вашего сервера может увеличиться из-за низкой скорости отклика внешнего ресурса.
Сообщение в журнале:
[30-Sep-2021 03:36:46] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
как раз и является доказательством увеличения нагрузки.
В обоих случаях следует определить причины нагрузки, проанализировав количество запросов к скриптам, и если есть обращения к внешним ресурсам, убедиться в их корректной работе.
Как вы можете видеть в выводе состояния
у вас есть задача, ожидающая запуска (5 активных, 0 бездействующих, 6 задач). Как вы написали в своем собственном ответе (, и я рад, что это сработало, )увеличение количества разрешенных дочерних элементов может быть хорошим решением -, но многое уходит на оптимизацию php-fpm, и, конечно же, прежде чем вносить эти изменения в конфигурацию, следует уделить больше внимания всей системе .
Твердое руководство здесь .
Но независимо от того, что вы должны знать при использовании статических значений:
if (использование памяти процессом *max_Children > RAM)
{ [crash apache] }
if (требования к обработке *start_servers > CPU)
{ [crash apache] }
И всегда знайте свое оборудование перед настройкой этих параметров, особенно в динамическом/по запросу (imo, легче ошибиться).
Если вы делаете это для любого типа критически важного веб-сервера для бизнеса, я бы хотел округлить, а затем удвоить все оценки. т.е. самый большой процесс, который можно вызвать, использует 178 МБ, поэтому 200 МБ, а ваша текущая виртуальная машина на [указать хостинг-провайдера/я] имеет только 1 ГБ ОЗУ -. Я бы установил для max_children значение 2--затем, когда вы обновите свою виртуальную машину, (что вы делаете с 1 ГБ в 2021 году??)и у вас есть 8 ГБ ОЗУ на вашем сервере, вы можете использовать max_children = 18 в обоих примерах округление идет в пользу дополнительных ресурсов, и после удвоения для целей fpm остается кусок памяти для ОС и других фоновых процессов.
Настройка этих параметров может быть чрезвычайно полезной, и любой, кто использует apache, должен знать, как это сделать. -Просто убедитесь, что ваше оборудование поддерживает установленную вами конфигурацию программного обеспечения.
В прошлом году у нас была почти такая же проблема.
Повышение максимального количества потомков только отодвинет проблему на более позднюю дату.
Оказалось, что это медленная база данных MySQL, размещенная на выделенном сервере в нашей сети для блога.
Наш PHP был настроен так, чтобы пытаться подключиться в течение 30 секунд, и всякий раз, когда эта база данных решала действовать, она пережевывала 100 дочерних элементов PHP.
Мы снизили его до 1 секунды, и проблема исчезла. Я не помню, была ли проблема с базой данных связана с сетью или нам пришлось оптимизировать саму базу данных.
Вы должны проверить свой журнал доступа Apache для этого периода времени 2 :30 -3 :30 и выяснить, являются ли они страницами, которые подключаются к базе данных. Проверьте журнал на наличие 500 ошибок, приведших к краху сервера.