Я не уверен, относится ли этот вопрос к ServerFault или StackOverflow, но поскольку я предполагаю, что мне нужно отладить эту проблему на стороне сервера, я выберу ServerFault.
Эта проблема
Мы запускаем общий сервер веб-хостинга для одного из наших клиентов. Все идет гладко, кроме одного клиента на своем сайте. Примерно 2–3 дня в неделю наш монитор обнаруживает кратковременный простой, потому что apache обслуживает страницу не в течение 30 секунд, а от 60 до 120 секунд. Один раз я проверил на своем рабочем столе, чтобы убедиться: веб-сайт продолжал загружаться в течение 80 секунд, а затем внезапно загружался. Повышенной нагрузки нет, запросов больше, чем обычно, и другие сайты на сервере загружаются отлично.
Ранее у нас были проблемы с конкретным плагином: этот плагин связывался с сервером от автора, чтобы подтвердить лицензионный ключ. Когда этот сервер был недоступен, Wordpress не мог продолжить загрузку и имел те же симптомы, что и сейчас. Мы заметили это, потому что однажды их сервер не работал на пару часов, и у нас было время отключить и включить все плагины, один за другим. По словам автора плагина, сейчас проблемы решены.
У меня сильное чувство, что мы снова сталкиваемся с той же проблемой, может быть, с тем же плагином, а может быть, и нет. Но поскольку время простоя такое короткое (обычно не более 2 минут), я понятия не имею, как отладить эту ошибку тайм-аута.
Вещи, о которых я думал
Обычно я отключаю плагины один за другим, но прежде чем я подключусь к базе данных, чтобы отключить плагины, веб-сайт снова заработал. Поскольку в простоях нет закономерности, я не могу оставаться в режиме ожидания, когда это произойдет. Журналы Apache не показывают никаких ошибок: я могу видеть только запросы пользователей и видеть, что в течение некоторого времени файлы не обслуживаются.
Вторая мысль заключалась в том, чтобы запустить трассировку стека для процесса apache. Я почти уверен, что это покажет, где Apache так долго ждет. Но поскольку сервер получает более 30 запросов в минуту, файл журнала станет очень большим за пару часов, что сделает невозможным поиск нужных запросов.
Соответствующие спецификации сервера
CentOS Linux release 7.0.1406 (Core)
Kernel 3.10.0-123.el7.x86_64
Apache/2.4.12 with mod_ruid2
PHP 5.4.38 (cli)
mysql Ver 15.1 Distrib 5.5.41-MariaDB, for Linux (x86_64) using readline 5.1
All compiled by DirectAdmin 1.48.3
Идеи?
Кто бы мог придумать хороший способ отладки этой очень специфической проблемы? Любая помощь приветствуется!
РЕДАКТИРОВАТЬ:
Как я уже упоминал, мы подозревали, что причиной проблемы был один из плагинов. Раньше, когда у них не работал лицензионный сервер, не работал и наш сайт. Они заявили, что эта проблема была исправлена в одном из последних обновлений, но, поскольку у нас так много времени простоя, я в этом сомневался.
В итоге мы отладили это следующим образом:
Последняя строчка strace была загрузкой файла: /wp-content/plugins/[plugin-name provided/[file-of-plugin] ].php. Apache не мог передать этот плагин, пока мы снова не разблокировали порт 80.
Мы удалили плагин, и с тех пор не было простоев. Это очень редкая проблема, но я надеюсь, что мой ответ может быть полезен, если кто-то другой сталкивается с той же проблемой.
Спасибо за все комментарии и ответы. Мы очень ценим это, это действительно помогло нам подумать над решением.
Если Apache все еще доступен, я бы сначала взял расширенную страницу статуса, чтобы увидеть, какие запросы обслуживаются прямо сейчас. Если есть длительный запрос, вы можете его даже привязать, pid должен быть виден в статусе (поскольку у вас есть mod_ruid2, я думаю, вы запускаете mod_php и prefork MPM, поэтому процесс будет обслуживать только один запрос за раз).
Возможно, переконфигурируйте Customlog и запишите время, затраченное на обслуживание запроса, чтобы позже вы могли определить медленные запросы.
Как только у вас появятся медленные запросы, посмотрите, можно ли их воспроизвести. Если да, то его легче отлаживать, вы даже можете добавить xdebug для профилирования / отладки PHP.
Также посмотрите, какие запросы MySQL выполняются во время зависания, возможно, это проблема с медленным запросом / блокировкой MySQL.
Как вы сказали, также может быть проблема с сетевым API.
А когда у вас кончатся все варианты, возможно, просто поговорите с боссом и выгните пользователя. В зависимости от того, сколько других сайтов находится на сервере, состояние сервера может быть более важным, чем сам сайт.