Ситуация - в понедельник начались жесткие тупняки апача периодические, после которых он отказывал. Иногда чудом вставал сам, чаще требовался рестарт.
Сервер выделенный в Хецнере, CentOS. Проект посещаемый, 45-50к / день. По хитам с учетом всяких системных (а-ля public_session.php) натикивает 40-50 запросов / сек для апача.
Два знакомых админа заявляют, что все чисто, никто не долбит, мол ищи проблемы в коде. Я как дурак прополз с фонариком по подозрительным местам, проанализировал все входящие хиты в рамках самой посещаемой минуты - ничего подозрительного.
Смущает меня и вот что:
1. Затуп начался в 13:30 Мск в понедельник. 2. Во вторник повторился в ЭТО ЖЕ время. Влияние скриптов по крону исключено. Отрубал агентов, крон, падать продолжал. 3. До понедельника НЕ БЫЛО такого вообще никогда, даже при пиках в ДВА раза больших. 4. Не ставились ни апдейты, ни софт. 5. Разработка на всем проекте не велась, ничего нового не добавлялось. Просто жил своей жизнью.
Я описал все это специально максимально подробно, что мне нужна 100% помощь. "Давай посмотрю, возможно помогу", к сожалению, не подходит. Ибо рут, все дела, проект довольно ценен. Но вынужден искать помощь на стороне. И да, в любом случае мне нужен админ на постоянку, которого мог бы теребить по случаю. Естественно, все за оплату.
Антон, у Хетзнер есть услуга "remote hands" - это что-то вроде удаленного администрирования их специалистом. Возможно тебе это подойдет. Раньше стоило кажется 25 евро пол часа.
Дороговато получается под 4к в час. Да и с нашим братом легче общаться когда дело тонких вещей касается.
В любом случае спасибо!
Вообще мне нравятся они http://centos-admin.ru/ , но дороговато, так как к ним надо садиться на постоянку (а за последние полгода это первая проблема, с которой я не могу сам справиться, или попросить по быстренькому знакомых, и вот ищу админов). Надеюсь, помогут разово, а там посмотрим.
Так как явным образом сказано, что "посмотрю, возможно помогу" не подходит, предлагать свою кандидатуру не стану. Тем не менее, на случай, если никто не откликнется, или проблему победить не получится, отмечу следующее:
Для перечисленных исходных данных:
один или несколько процессов Apache начинает использовать 100% CPU;
проблема проявляется в произвольный момент времени;
через некоторое время все может прийти в норму.
Наиболее частым объяснением является существование PHP скрипта, в котором организован бесконечный или чрезвычайно "длинный" цикл.
Типичная ситуация: поисковый робот нашел ссылку на старый отладочный скрипт, или подобрал "неудачный" набор параметров к рабочему скрипту, который делает внутри себя бесконечное зацикливание. При этом:
так как роботы имеют тенденцию заходить в одно и то же время, проблема часто проявляется в конкретные часы;
так как "неудачная" ссылка как правило одна и робот обращается к ней один-два раза, парализованными оказываются один-два процесса Apache;
через некоторое время работа скрипта прекращается по timeout и ситуация может нормализоваться;
если ссылка была запрошена большое количество раз и затронула большое число процессов Apache, нормализовать ситуацию может уже лишь перезапуск сервиса.
Поиск проблемной ссылки в таких случаях осуществляется с помощью модуля Apache, который называется mod_status.
Первым делом следует проверить, что:
Существует файл /etc/httpd/modules/mod_status.so. Модуль mod_status традиционно идет в комплекте вместе с Apache, потому шансы его не обнаружить крайне низки, но тем не менее, убедиться все-таки стоит.
В файле /etc/httpd/conf/httpd.conf присутствуют и раскомментированы строки:
Код
LoadModule status_module modules/mod_status.so
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
Указанные строки могут находиться в разных частях конфигурационного файла. Блок Location может иметь другой набор разрешительных правил, в зависимости от настроек системы мониторинга.
Если чего-то из перечисленного нет, то следует добавить, после чего проверить корректность конфигурации (apachectl configtest) и перезапустить Apache (apachectl graceful).
Начиная с этого момента Apache предоставляет информацию об обрабатываемых запросах. Чтобы получить эту информацию, можно, например, выполнить команду:
После чего открыть /tmp/server_status.html в lynx, mcview или в браузере, предварительно скачав на локальную машину. Результат будет иметь следующий вид. Далее остается лишь посмотреть, обращение к какому адресу вызывает загрузку CPU и провести анализ кода PHP для найденной ссылки.
У меня было дело положил сервер бесконечной рекурсией Еще может в шаблоне/компоненте каком-то есть тяжелые вычисления. Мимо кэша - сервер вешает, потом когда из кэша читается - все нормально работает.
Иван, большое спасибо, рассуждения очень здравые. Но не смотря на большую посещаемость в проекте не так много кода, чтобы я какую-то часть где-то забыл или не знал (все прошло через меня). Плюс, как и писал, я проанализировал хиты тормозной минуты (да и другие смотрел поверхностно), ничего сверхъестественного.
Вчера он сам отлег и больше не падал. И опять ничего не менялось ни в коде ни в апдейтах. Меня это бесит.
Запросил еще у админов ситуацию, посмотрим что скажут.
Антон, еще можно перестраховаться убедившись что все впорядке с железом (винтами). На Хетзнере у меня были проблемы с работоспособностью (периодические, правда выглядели не так как у Вас) когда начал умирать 1 винт из raid-а.