Форум

Антон, у Хетзнер есть услуга "remote hands"  - это что-то вроде удаленного администрирования их специалистом.
Возможно тебе это подойдет. Раньше стоило кажется 25 евро пол часа.

Так как явным образом сказано, что "посмотрю, возможно помогу" не подходит, предлагать свою кандидатуру не стану. Тем не менее, на случай, если никто не откликнется, или проблему победить не получится, отмечу следующее:

Для перечисленных исходных данных:

• один или несколько процессов Apache начинает использовать 100% CPU;
  
• проблема проявляется в произвольный момент времени;
  
• через некоторое время все может прийти в норму.
  

Наиболее частым объяснением является существование PHP скрипта, в котором организован бесконечный или чрезвычайно "длинный" цикл.

Типичная ситуация: поисковый робот нашел ссылку на старый отладочный скрипт, или подобрал "неудачный" набор параметров к рабочему скрипту, который делает внутри себя бесконечное зацикливание. При этом:

• так как роботы имеют тенденцию заходить в одно и то же время, проблема часто проявляется в конкретные часы;
  
• так как "неудачная" ссылка как правило одна и робот обращается к ней один-два раза, парализованными оказываются один-два процесса Apache;
  
• через некоторое время работа скрипта прекращается по timeout и ситуация может нормализоваться;
  
• если ссылка была запрошена большое количество раз и затронула большое число процессов Apache, нормализовать ситуацию может уже лишь перезапуск сервиса.
  

Поиск проблемной ссылки в таких случаях осуществляется с помощью модуля Apache, который называется mod_status.

Первым делом следует проверить, что:

1. Существует файл /etc/httpd/modules/mod_status.so. Модуль mod_status традиционно идет в комплекте вместе с Apache, потому шансы его не обнаружить крайне низки, но тем не менее, убедиться все-таки стоит.
   
2. В файле /etc/httpd/conf/httpd.conf присутствуют и раскомментированы строки:
   

Указанные строки могут находиться в разных частях конфигурационного файла. Блок Location может иметь другой набор разрешительных правил, в зависимости от настроек системы мониторинга.

Если чего-то из перечисленного нет, то следует добавить, после чего проверить корректность конфигурации (apachectl configtest) и перезапустить Apache (apachectl graceful).

Начиная с этого момента Apache предоставляет информацию об обрабатываемых запросах. Чтобы получить эту информацию, можно, например, выполнить команду:


После чего открыть /tmp/server_status.html в lynx, mcview или в браузере, предварительно скачав на локальную машину. Результат будет иметь следующий вид. Далее остается лишь посмотреть, обращение к какому адресу вызывает загрузку CPU и провести анализ кода PHP для найденной ссылки.

Иван, большое спасибо, рассуждения очень здравые. Но не смотря на большую посещаемость в проекте не так много кода, чтобы я какую-то часть где-то забыл или не знал (все прошло через меня).
Плюс, как и писал, я проанализировал хиты тормозной минуты (да и другие смотрел поверхностно), ничего сверхъестественного.

Вчера он сам отлег и больше не падал. И опять ничего не менялось ни в коде ни в апдейтах. Меня это бесит.

Запросил еще у админов ситуацию, посмотрим что скажут.

Антон, еще можно перестраховаться убедившись что все впорядке с железом (винтами).
На Хетзнере у меня были проблемы с работоспособностью (периодические, правда выглядели не так как у Вас) когда начал умирать 1 винт из raid-а.