Как исправить нестабильность Apache?
Я настроил простой стек LAMP в Debian, и у меня возникли некоторые проблемы с веб-сервером Apache.
Каждые 3-4 часа веб-сервер входит в тупик и все запросы попадают в блокировку базы данных. Сервер создает новый дочерний элемент для каждого запроса. Количество процессов очень быстро увеличивается. Через несколько секунд Monit замечает, что что-то не так, и перезапускает сервер Apache.
Я подозреваю, что эта проблема вызвана тем, как PHP обрабатывает пул соединений с базой данных, потому что сервер все еще может отвечать на запросы статического содержимого. Вы сталкивались с таким поведением? Что мне делать?
Обновлять: Проблема решена. Похоже, использовать APC для кэширования опкодов и пользовательских данных - плохая идея. Сейчас я использую Memcache для хранения пользовательских данных и APC только для кода. Время от времени у меня все еще возникают ошибки сегментации, но в большинстве случаев сервер работает стабильно.
да. Сервер mysql продолжает работать нормально.
Ответы 4
Почему бы тебе не посмотреть журналы? /var/log/apache2/* - хорошее место для начала. Что запрашивается непосредственно перед тем, как сервер умирает? Оттуда вы, вероятно, сможете понять, что идет не так. Поскольку скрипты php по умолчанию завершаются через 30 секунд, ошибка должна быть довольно большой, чтобы вызвать что-то подобное.
В журнале ошибок нет сообщений. Я запустил strace для заблокированного ребенка, и он ждал после фьютекса. Я думаю, что есть проблема в коде, соединяющем php с сервером mysql, потому что в то же время сервер мог обрабатывать запросы к статическому контенту.
Проверьте настройки тайм-аута в /etc/apache2/apache2.conf, я видел аналогичные проблемы, когда тайм-аут был установлен большим, и система поражалась кучей разорванных соединений.
таймаут установлен на 100. это значение слишком велико?
Если вас не ударит червь, который разрывает соединения, не закрывая их, это должно быть нормально (я сам использую 60).
Я подозреваю, что проблемы в следующем:
- Сложный длительный запрос к базе данных, который блокирует дальнейшие запросы. Это довольно просто, если вы используете механизм MySQL MyISAM, который имеет только блокировку на уровне таблицы, а считыватели могут легко блокировать писателей и наоборот, поэтому один сложный запрос, скажем, к таблице пользователя, может в значительной степени заблокировать весь сервер, в то время как база данных ожидает ввода-вывода. Обычно вы можете диагностировать это, используя «SHOW PROCESSLIST» или инструмент, который сделает это за вас.
- Установив MaxClients слишком высоко для оперативной памяти, доступной на сервере prefork - почти все делают это. Если вы используете «толстый» предварительный форк Apache (например, с внутрипроцессным PHP), то не устанавливайте MaxClients выше, чем у вас достаточно оперативной памяти. Вероятно, это намного меньше типичных значений 100 или 150.
Эти две вещи вместе создают проблему, которую вы видите. Их необходимо исправить, поскольку они сами по себе могут вызвать проблемы.
Это полностью основано на догадках и опыте.
Мы используем InnoDB. Я улучшу наши сценарии мониторинга, чтобы сохранить вывод SHOW PROCESS LIST, когда Apache блокируется, но я думаю, что у нас не работает странный запрос. На сервере много оперативной памяти, память подкачки никогда не используется.
Журнал mysql-slow также полезен для поиска медленных запросов, вызывающих проблемы.
Вы проверили, не проблема ли это на уровне сервера MySQL? Вы сказали, что статический контент можно обслуживать, можете ли вы подключиться к базе данных с помощью других инструментов?