Apache fcgid php «Работает» простаивающие процессы php
У нас возникла проблема, из-за которой PHP-процессы Apache (2.4.10) FCGID (2.3.9) застряли в «Работающем» состоянии Debian.
Эти PHP-процессы не занимают системных ресурсов (кроме того, что они занимали ранее использовавшуюся память при обработке предыдущих запросов) и бездействуют.
Они все еще привязаны к правильному логическому родительскому процессу (процесс apache2, обрабатывающий запросы на этом vhost)
Соединяясь с ними, вы обнаружите, что они находятся в состоянии:
принимаем (0,
Мы предполагаем прослушивание, чтобы получить следующий запрос.
Ведение журнала приложения, добавленное при нашей обработке PHP в функции handle_shutdown, показывает, что все эти запросы достигли функции handle_shutdown (без ошибок) — как и следовало ожидать для любого обработанного запроса PHP (так как вы всегда нажимаете на функцию handle_shutdown), так что в лучшую сторону насколько нам известно, весь запрос «успешно». Ответ 200 регистрируется в журнале доступа Apache.
Однако в разделе fcgid apachectl fullstatus показано, что процесс работает, а не готов
Изменение коэффициентов рециркуляции в настройках Fcgid (максимальное количество запросов, время жизни, время ожидания, установленное выше или ниже и т. Д.), По-видимому, не влияет на регулярность этих событий.
Изящный apachectl успешно очищает все свободные рабочие потоки и возвращается в нормальное состояние.
Однако, конечно, если мы оставим это без наблюдения, в конце концов, каждый из процессов рано или поздно окажется в этом состоянии, пока мы не получим полностью бездействующий сервер, на котором все наши максимальные процессы (100) застряли «Ожидание «но без дела. На этом этапе использование памяти является разумным, и, конечно, загрузка ЦП, сети и др. Пренебрежимо мала, поскольку единственный запрос, на который сервер будет отвечать, это полный статус (поскольку он не затрагивает раздел PHP vhost)
Решение
Что ж.
Оказывается, что первый предложенный ответ (установите для режима Mutex apache2 значение «sem» из файла: «был правильным, но когда он был применен впервые — наши службы apache2 были запущены не в холодном режиме, но перезапущен поэтому, конечно, новый режим Mutex фактически не использовался.
Таким образом, когда тестирование все еще показало ошибку, это предложение было списано.
Что происходит?
Процесс apache2 fcgid PM хранит три списка всех текущих дочерних процессов: «Готов», «Работает» и «Ошибка / Выход».
Он использует мьютекс (блокировку) для защиты этих списков всякий раз, когда он перемещает информационный блок дочерних процессов из «Готово» в «Ожидание», когда он дает ему запрос на обработку, и снова, когда дочерний процесс завершает запрос, в порядке переместить его обратно в «Готово».
Этот мьютекс защищает общий ресурс, доступ к которому осуществляется из нескольких потоков или процессов, от возможности «переопределения» одним процессом, в то время как другой процесс также пытается прочитать или записать значение (в результате чего другой процесс либо прочитал несовместимое значение, или чтобы его запись терялась), позволяя только одному процессу одновременно получать доступ к этому жизненно важному ресурсу.
Мьютексы «file:» по умолчанию в Debian, кажется, не подходят для задания, вызывающего очень редко (как это предлагается в другом месте в сети), когда два запроса на изменение состояния происходят одновременно, и, таким образом, одно изменение успешно, в то время как другое (одновременное) Изменения теряются.
Таким образом, ребенок, зная, что он закончил, а родитель думал, что это не так.
Хмм!
Мораль: в Debian измените режим мьютекса, если используете apache2 с fcgid — и убедитесь, что вы сделали полную остановку apache с последующим запуском apache, и не доверяйте администраторам своего сервера, которые только перезапустили apache!
Другие решения
Других решений пока нет …