Есть следующий беда.
С недавних времён, Apache стал грузить процессор на сервере на все 100% при непонятных обстоятельствах. Зависимости никакой найти не могу, кроме того, что после перезагрузки он какое то время живёт спокойно, может час а может и несколько часов, ночь день не важно.
Когда начинается, грузит он его не постоянно, с маленькими перерывами (минута две три) в такой перерыв, ребутаю систему и живу несколько часов спокойно. Но если уж он начал своё чёрное дело, то это на несколько часов.
Сервак на Intel(R) Xeon(R) CPU E5310 @ 1.60GHz с 1 Gb оперативы.
Debian Linux 5
Стоит WEBMIN
Сайтов осталось три, нагрузка на них маленькая. Все они работали спокойно до этого по нескольку месяцев.
Сам я лично в Linux ноль полный. Сервак настраивали другие люди и админил другой человек но он потерялся
Когда началось, я удалил все виртуальные хосты и папки с не моими сайтами, которые висели на серваке. Сайты друга были.
Когда Apache не бесится, всё работает на ура. Памяти занято до 200 Мб. Все запросы обрабатываются без проблем.
Как мог удалил всякую вигню, убрал задания в cron, связанные с резервным копированием, короче на что хватило мозгов, сделал.
Что это такое понять не могу.
Написал скрипт, который каждые 30 секунд пингует сервак и если он не доступен пишет время в текстуху. По ней слежу в какие моменты Apach бесится
Какие мысли народ.
Apache нагружает процесор на 100%
Сам я лично в Linux ноль полный
===
удалил всякую вигню
убрал задания в cron
Написал скрипт

Точно Apache грузит?
Дилетантский совет:
-смотреть логи в
/var/log/apache2-посмотреть активные соединения
sudo netstat -tupТочно Apache грузит?
Вот он
Вроде он.
вот последнее что пишет лог apacha error
[Fri Sep 28 18:10:59 2012] [error] [client 178.154.243.110] File does not exist: /var/www/robots.txt
[Fri Sep 28 20:14:23 2012] [notice] caught SIGTERM, shutting down
[Fri Sep 28 20:16:25 2012] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Fri Sep 28 20:16:25 2012] [notice] mod_python: using mutex_directory /tmp
[Fri Sep 28 20:16:25 2012] [notice] Apache/2.2.9 (Debian) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
[Fri Sep 28 20:27:25 2012] [error] [client 62.109.28.1] File does not exist: /var/www/ru
[Fri Sep 28 20:44:29 2012] [error] [client 188.72.80.220] File does not exist: /var/www/robots.txt
[Fri Sep 28 20:44:29 2012] [error] [client 188.72.80.220] File does not exist: /var/www/ru
[Fri Sep 28 21:08:49 2012] [notice] caught SIGTERM, shutting down
[Fri Sep 28 21:10:46 2012] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Fri Sep 28 21:10:46 2012] [notice] mod_python: using mutex_directory /tmp
[Fri Sep 28 21:10:46 2012] [notice] Apache/2.2.9 (Debian) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
[Fri Sep 28 21:32:43 2012] [error] [client 77.122.10.8] File does not exist: /var/www/img, referer: http://galaxy-sim.ru/index.php?/topic/496-gnn/
[Fri Sep 28 22:31:07 2012] [notice] caught SIGTERM, shutting down
[Fri Sep 28 22:33:04 2012] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Fri Sep 28 22:33:04 2012] [notice] mod_python: using mutex_directory /tmp
[Fri Sep 28 22:33:04 2012] [notice] Apache/2.2.9 (Debian) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
[Fri Sep 28 22:36:14 2012] [error] [client 157.55.35.36] File does not exist: /var/www/robots.txt
[Fri Sep 28 23:28:12 2012] [error] [client 62.109.28.1] File does not exist: /var/www/ru
[Fri Sep 28 23:34:58 2012] [error] [client 180.76.5.188] File does not exist: /var/www/robots.txt
[Fri Sep 28 23:34:58 2012] [error] [client 180.76.5.141] File does not exist: /var/www/robots.txt
[Fri Sep 28 23:36:52 2012] [error] [client 217.69.133.30] File does not exist: /var/www/img
[Sat Sep 29 00:00:40 2012] [notice] caught SIGTERM, shutting down
[Sat Sep 29 00:02:35 2012] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Sat Sep 29 00:02:35 2012] [notice] mod_python: using mutex_directory /tmp
[Sat Sep 29 00:02:35 2012] [notice] Apache/2.2.9 (Debian) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations
[Sat Sep 29 00:46:57 2012] [error] [client 89.108.74.124] script '/var/www/licver.php' not found or unable to stat
посмотреть активные соединения
Посмотрел, кроме меня никого ) Нужно будет посмотреть когда опять начнёт своё дело гадское )
Картинка
Для просмотра этой страницы необходимо зарегистрироваться.
Нужно будет посмотреть когда опять начнёт своё дело гадское )
Ага. Ну и
access.log гляньте.
Случайно ISPmanager не стоит?
Swap - раздела у вас нет что ли?
Может есть зависимость между зависаниями и записями в access.log ?
Случайно ISPmanager не стоит?
Не, эта беда не стоит. Погуглил.
з.ы
Пойду спать. Спасибо за отзыв. Давайте в вс. продолжим если не сложно.
Текстовые данные лучше копипастить прямо сюда, заключая в теги code...
Мне кажутся подозрительными строки с этим ботом:
[Fri Sep 28 20:27:25 2012] [error] [client 62.109.28.1] File does not exist: /var/www/ru
[Fri Sep 28 23:28:12 2012] [error] [client 62.109.28.1] File does not exist: /var/www/ru
SetLinks bot
SetLinks bot
Setlinks bot наверное и раньше работал, у меня на сайте одном ссылки с этого сервиса, уже давно. Сегодня сделал в cron вот что renice +10 -u www-data
Каждый час выполнять, вроде вся суббота без приключений, посмотрю дальше как будет.
Короче, вроде нормализовалась работа. Осталось выяснить почему :)
Последнее действие после которого неделю работает было удаление дополнительного ip в Сервер DNS BIND в разделе "Другие серверы ДНС" Там был какой то иностранный ip, от старого управленца остался видать. Так же уменьшил жизнь сессиии в php но это не важно.
Вот вопрос. Если были на серваке сайты на которые заходили в основном с иностранных ip и был дополнительный ip в ДНС, могло это влиять на апач после того как были удалены эти сайты с сервера?
Конфиг bind'а надо выложить. И вообще всегда конфиги первым делом показывать надо, а то так и будет все вокруг да около.
Конфиг bind'а надо выложить. И вообще всегда конфиги первым делом показывать надо, а то так и будет все вокруг да около.
Если можно, скажите пожалуйста, какие именно файлы конфига показать?
Если можно, скажите пожалуйста, какие именно файлы конфига показать?
Странно видеть данный вопрос, учитывая:
было удаление дополнительного ip в Сервер DNS BIND в разделе "Другие серверы ДНС" Там был какой то иностранный ip, от старого управленца остался видать.
.
Пытаюсь додумать сам, - наверное проблема вся была в резолве днс адресов.
Лучшим способом будет самому настроить bind заново, с нуля, заодно и разберетесь что к чему.
Лучшим способом будет самому настроить bind заново, с нуля, заодно и разберетесь что к чему.
Ужо читаю :)