Выявление причин торможения системы [РЕШЕНО]
ClearKbdBuf 8 июля, 2010 - 09:05
Добрый день!
Имеется сервер на базе ОС Linux Gentoo. На сервере работают DHCP, DNS, Squid, SSH, Apache (Cacti, Nagios (мониторятся 1443 узла), Sarg).
Недавно сервер начал дико тормозить. Торможение проявляется в медленной работе SSH-сессии, а так же скорость доступа в инет значительно снизилась. Грешил на нагиос, но раньше ведь работал, при этом, я сознательно не стал настраивать значки для отображения узлов и оповещения.
Подскажите, пожалуйста, с чего следует начать диагностику в данном случае?
С уважением!
»
- Для комментирования войдите или зарегистрируйтесь
,
Если вы уверены что проблема внутрення (т.е. никто не ддосит), я бы начал проверять с нагиоса (все-таки 1.5к хостов) и squid. Попробуйте останавливать их во время тормозов.
А в top-е ничего не видно?
DDoSа нет
Судя по нагрузке на внешний интерфейс, никто не ДДоСит.
В топе вот что, на мой взгляд, все ок:
top - 18:12:11 up 8 days, 1:26, 4 users, load average: 32.87, 31.85, 30.86 Tasks: 174 total, 2 running, 169 sleeping, 0 stopped, 3 zombie Cpu(s): 1.0%us, 2.6%sy, 0.0%ni, 0.0%id, 95.4%wa, 0.7%hi, 0.3%si, 0.0%st Mem: 504200k total, 414476k used, 89724k free, 225400k buffers Swap: 506036k total, 82376k used, 423660k free, 42836k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18415 squid 20 0 27564 16m 1660 R 0.4 3.3 8:14.26 squid 4727 nagios 20 0 20784 5160 756 D 0.2 1.0 302:21.46 nagios 6204 apache 20 0 0 0 0 Z 0.2 0.0 0:00.13 apache2 <defunct> 6428 root 20 0 2504 1196 884 R 0.2 0.2 0:00.03 top 12757 root 20 0 3336 1000 556 D 0.2 0.2 0:10.01 chown 18634 root 20 0 3336 1180 552 D 0.2 0.2 0:35.51 chown 21205 root 20 0 3336 1184 552 D 0.2 0.2 0:22.62 chown 22217 root 20 0 3336 1164 544 D 0.2 0.2 0:47.07 chown 29667 root 20 0 3336 1180 552 D 0.2 0.2 0:41.35 chown 1 root 20 0 1700 476 452 S 0.0 0.1 3:58.83 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.45 kthreadd 3 root 15 -5 0 0 0 S 0.0 0.0 13:45.04 ksoftirqd/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.68 events/0 5 root 15 -5 0 0 0 S 0.0 0.0 0:00.02 khelper 8 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 netns 183 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0 185 root 15 -5 0 0 0 S 0.0 0.0 23:52.07 kblockd/0Squid, Nagios, Apache остановил, ситуация не улучшилась.
http://clearkbdbuf.livejournal.com
Очередь IO большая. Скорее
Очередь IO большая. Скорее всего проявление бага который еще не исправили. Пробуй менять планировщик ввода-вывода.
И iotop может помочь узнать какой процесс грузит диск.
,
впечатляет )
Досить могут и на внутреннем ифейсе (вирусы например).
А что за chown процессы работающие по 41 секунде?
Цитата: load average: 32.87,
В смысле?
На внутреннем интерфейсе так же нет нагрузки, способной вызвать торможение.
http://clearkbdbuf.livejournal.com
По приведенному топу видно,
По приведенному топу видно, что система в хлам загружена I/O wait. Т.е. - идет активная работа скорее всего с винтом, точнее, с ФС. Это может быть, например, из-за того, что в некоторых каталогах лежит более 20000 файлов. А если такой каталог не один - это вообще вилы.
Как это происходит: процесс вызывает open(), драйвер ФС ищет файл по пути, создает дескриптор и передает его в процесс. Выделенное жирным выполняется ядром, и если каталог содержит очень большое кол-во файлов - на эту операцию уходит довольно много времени. Процессор в это время не загружен, но все процессы, которым нужен в данный момент I/O, вынуждены ожидать, пока будет завершена операция поиска.
Если вызовов open() в больших каталогах много - система будет парализована, поскольку будет тратить время на I/O.
ОНО!
Да, действительно, это было именно оно!
Причина была в том, что я не чистил статистику sarg с июля прошлого года. Соответственно в каталоге сарджа было очень много файлов. Похерил, тормоза прошли. Вот вывод top (кстати и процессы chown исчезли):
top - 11:11:46 up 12 days, 18:26, 2 users, load average: 0.81, 1.15, 1.28 Tasks: 80 total, 2 running, 76 sleeping, 0 stopped, 2 zombie Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 504200k total, 212540k used, 291660k free, 46244k buffers Swap: 506036k total, 64184k used, 441852k free, 51716k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10800 squid 20 0 27044 12m 1648 S 0.7 2.6 14:03.50 squid 1 root 20 0 1700 432 408 S 0.0 0.1 4:57.72 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.60 kthreadd 3 root 15 -5 0 0 0 S 0.0 0.0 17:24.04 ksoftirqd/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.91 events/0 5 root 15 -5 0 0 0 S 0.0 0.0 0:00.02 khelper 8 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 netns 183 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0 185 root 15 -5 0 0 0 S 0.0 0.0 37:38.31 kblockd/0 188 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid 189 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify 241 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue 248 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0 249 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux 250 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksuspend_usbd 255 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khubd 258 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriodСпасибо огромное за помощь!
Подскажите, пожалуйста, на всякий случай, есть ли способ поиска каталогов с большим количеством файлов кроме написания собственного скрипта?
http://clearkbdbuf.livejournal.com
Из того, что знаю я, разве
Из того, что знаю я, разве что du подойдет, но скрипт все равно писать надо. Я сам хотел давно уже написать что-то для такого поиска (не скрипт), да все руки не доходят. Может, после отпуска напишу.
Пока что написал программу, которая удаляет все файлы из указанного каталога, независимо от того, сколько их там. Был у меня случай, когда 'rm -r /path/*' дал ответ "недостаточно памяти", и поскольку я не знал, как грохнуть содержимое папки по-другому, пришлось писать свой софт.
.
Это происходит из-за того, что список аргументов для rm (*) очень длинный получается. Лечится через xargs или find:
ls /path/ | xargs -L 10 rm -rМда. Правильно говорят: век
Мда. Правильно говорят: век живи, век учись... Спасибо! :)
Спасибо!
Огромное спасибо за консультацию!
http://clearkbdbuf.livejournal.com
А что в syslog'e? Мож у вас
А что в syslog'e?
Мож у вас диск дохнет... :)
Или места мало, или ...
syslog
В сислоге основная часть сообщений идут от нагиоса.
При этом меня смутило то, что сислог пытается отправить почту:
Таких сообщений очень много. Мож в этом дело?
Есть ли возможность запретить ему делать это?
Что касается дискового пространства то, место вроде есть:
Можно ли проверить состояние винта без останова системы?
http://clearkbdbuf.livejournal.com
.
А еще посмотрите
df -i/Не знаю, существует ли потенциальный риск окончания инодов на вашей ФС, но у меня когдато кончились на ufs
df -i
Вот:
у меня на hda3 ReiserFS, там вроде айноды не используются, поэтому и 0 стоит.
http://clearkbdbuf.livejournal.com
ClearKbdBuf написал(а): В
Если пытается отправить - значит есть, что сказать! :)
Запретить нельзя, да и зачем?! Лучше в /etc/hosts пропишите правильный mail.
sys-apps/smartmontools
Спасибо
Спасибо!
http://clearkbdbuf.livejournal.com
У меня на работе такая беда
У меня на работе такая беда была..
И если это началось, то дальше будет хуже.
мои советы:
- чеки в нагиос запускать по nrpe (если еще не делаешь так) - Могу поспорить, что это именно его тысячи процессов тебя лоудят.
- поставить на каждую задачу по виртуальной машине. будешь знать, что тебя тормозит.
- вынести cacti (на сколько я понял там тоже 1.5к хостов) на отдельный диск.
- увеличить число каталогов в сквиде. И тоже отдельный диск по возможности.
P.S. htop, iotop тебе в руки
Olek написал(а): У меня на
- нагиос не тормозит, вренее систему нагружает, но вмеру;
- в кактусе мониторятся только магистральные каналы;
- после устранения проблемыы (см. выше) сквид перестал тормозить.
http://clearkbdbuf.livejournal.com