Вопрос или проблема
У меня есть сервер с Apache 2.4.38 на Debian 10, и иногда веб-сервер работает неправильно и не отправляет немедленно ответ на HTTP-запросы, которые он получает (все запросы виртуальных хостов на нем полностью неотвечают (независимо от того, к чему они обратные прокси)). После перезагрузки он сразу же восстанавливается или после того, как так работает некоторое время (секунды или даже минуты), и вдруг начинает отправлять ОЧЕНЬ много HTTP-ответов.
Использование ЦП и ОЗУ, похоже, в норме, так что это определенно не в этом. Я не знаю, что именно происходит и почему это происходит.
Я также изменил настройки mpm_event.conf, сейчас они установлены на следующее:
<IfModule mpm_event_module>
StartServers 2
ServerLimit 100
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 128
ThreadsPerChild 25
MaxRequestWorkers 400
MaxConnectionsPerChild 5000
</IfModule>
Тем не менее, есть несколько ошибок, которые я видел в журнале ошибок Apache:
[Tue Mar 22 19:53:38.339703 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 29595 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.339777 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 26190 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.339825 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 27903 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.339889 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 16907 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.339933 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 26880 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.340000 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 15384 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.340041 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 24971 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.340091 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 9780 все еще не вышел, отправка SIGKILL
[Tue Mar 22 19:53:38.340130 2022] [core:error] [pid 3375:tid 140244229465216] AH00046: дочерний процесс 26317 все еще не вышел, отправка SIGKILL
Какие настройки я могу изменить, чтобы исправить эту проблему?
Похоже, что что-то зависает в ваших рабочих процессах. Это плохо. Либо какой-то плагин зависает, либо у вас могут быть проблемы с оборудованием. Менее вероятно, что вы нашли ошибку в Apache.
Я бы проверил dmesg и systemctl на наличие ошибок, особенно связанных с хранилищем.
Если этот простой проверка ничего не даст, прикрепите gdb к вашему процессу apache2 и посмотрите, где именно дочерние процессы зависают, не выходя. Возможно, это плагин, который пытается разрешить имя, и разрешение случайно недоступно? Возможно, это доступ к ненадежно доступному файлу на NFS? Трудно сказать отсюда.
Ответ или решение
Проблема, которую вы описали, связана с работой вашего веб-сервера Apache 2.4.38 на платформе Debian 10. Замедление обработки запросов и неожиданное застревание дочерних процессов могут иметь несколько причин, и решение этой проблемы требует комплексного подхода. Рассмотрим основные аспекты и предлагаемые действия для выявления и устранения проблемы.
1. Анализ ошибок в логах
Согласно приведённым вами записям из логов Apache, мы видим, что происходит нечто критическое — дочерние процессы не завершаются и получают сигнал SIGKILL. Это может указывать на зависание процессов, которое может быть вызвано:
- Блокировкой ресурсов: Проверьте внешние системы, к которым обращается ваш сервер (например, базы данных, файловые системы и API). Если какой-то из сервисов будет недоступен или медленно отвечать, это может привести к подобным зависаниям.
- Ошибками в конфигурации модулей: Неправильно настроенные модули могут приводить к зависаниям. Убедитесь, что все ваши модули обновлены и сконфигурированы должным образом.
2. Настройки MPM Event
Согласно вашему конфигурационному файлу mpm_event.conf, у вас есть настройки, которые вполне могут потребовать оптимизации:
<IfModule mpm_event_module>
StartServers 2
ServerLimit 100
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 128
ThreadsPerChild 25
MaxRequestWorkers 400
MaxConnectionsPerChild 5000
</IfModule>- MaxRequestWorkers и ServerLimit: Убедитесь, что значение
MaxRequestWorkersне превышает возможности вашего сервера. Если у вас слишком много активных процессов, это может привести к исчерпанию ресурсов. - ThreadsPerChild: Попробуйте увеличить количество потоков на процесс, чтобы улучшить параллельную обработку запросов. Например, можно увеличить это значение до 50, чтобы проверить, улучшится ли обработка.
3. Дополнительные проверки
- Системные ресурсы: Даже если CPU и RAM выглядят нормально, проверьте нагрузку на диск, особенно если вы используете сеть (NFS) или проводите высоконагруженные операции. Используйте команды
iotopилиdstat, чтобы оценить загрузку ввода/вывода. - dmesg и systemctl: Проверьте наличие ошибок в системных журналах. Любые сообщения о сбоях или предупреждениях могут подсказать о наличии проблем с оборудованием или драйверами.
- Отладка с использованием gdb: Подключите gdb к процессу Apache, чтобы определить, в каком именно состоянии зависли ваши процессы. Это может указать на конкретные проблемные участки в коде или модулях.
4. Альтернативные подходы
- Модульное тестирование: Если вы используете сторонние модули или плагины, попробуйте временно их отключить. Это может помочь вам выяснить, не является ли один из них причиной зависаний.
- Наблюдение за сетью: Убедитесь, что нет сетевых проблем, включая DNS. Иногда сервер может зависнуть, ожидая разрешения доменных имен, если DNS-сервер недоступен.
Заключение
При устранении проблемы с зависающими запросами на Apache нужно обратить внимание на множество факторов. Постепенное внесение изменений в настройки, контроль за работой системы и отказ от потенциально проблемных модулей — это основные шаги, способствующие восстановлению стабильности работы вашего веб-сервера. Если проблема не будет решена, возможно, стоит рассмотреть вариант обращения к профессиональным администраторам для глубокой диагностики системы.