Выявление причин торможения системы [РЕШЕНО]

Добрый день!

Имеется сервер на базе ОС 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/0

Squid, Nagios, Apache остановил, ситуация не улучшилась.

Очередь IO большая. Скорее

Очередь IO большая. Скорее всего проявление бага который еще не исправили. Пробуй менять планировщик ввода-вывода.
И iotop может помочь узнать какой процесс грузит диск.

,

Цитата:
load average: 32.87, 31.85, 30.86

впечатляет )

Досить могут и на внутреннем ифейсе (вирусы например).
А что за chown процессы работающие по 41 секунде?

Цитата: load average: 32.87,

Цитата:
load average: 32.87, 31.85, 30.86
впечатляет )

В смысле?

Цитата:
Досить могут и на внутреннем ифейсе (вирусы например).

На внутреннем интерфейсе так же нет нагрузки, способной вызвать торможение.

По приведенному топу видно,

По приведенному топу видно, что система в хлам загружена 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

Спасибо огромное за помощь!

Подскажите, пожалуйста, на всякий случай, есть ли способ поиска каталогов с большим количеством файлов кроме написания собственного скрипта?

Из того, что знаю я, разве

Из того, что знаю я, разве что du подойдет, но скрипт все равно писать надо. Я сам хотел давно уже написать что-то для такого поиска (не скрипт), да все руки не доходят. Может, после отпуска напишу.
Пока что написал программу, которая удаляет все файлы из указанного каталога, независимо от того, сколько их там. Был у меня случай, когда 'rm -r /path/*' дал ответ "недостаточно памяти", и поскольку я не знал, как грохнуть содержимое папки по-другому, пришлось писать свой софт.

.

alexpro написал(а):
случай, когда 'rm -r /path/*' дал ответ "недостаточно памяти"

Это происходит из-за того, что список аргументов для rm (*) очень длинный получается. Лечится через xargs или find:
ls /path/ | xargs -L 10 rm -r

Мда. Правильно говорят: век

Мда. Правильно говорят: век живи, век учись... Спасибо! :)

Спасибо!

Огромное спасибо за консультацию!

А что в syslog'e? Мож у вас

А что в syslog'e?
Мож у вас диск дохнет... :)
Или места мало, или ...

syslog

В сислоге основная часть сообщений идут от нагиоса.
При этом меня смутило то, что сислог пытается отправить почту:

May 22 15:01:18 officemanager sSMTP[13471]: Unable to locate mail
May 22 15:01:18 officemanager sSMTP[13471]: Cannot open mail:25

Таких сообщений очень много. Мож в этом дело?
Есть ли возможность запретить ему делать это?

Что касается дискового пространства то, место вроде есть:

df -a

Файловая система     1K-блоков      Исп  Доступно  Исп% смонтирована на
/dev/hda3             38530660  18410052  20120608  48% /
proc                         0         0         0   -  /proc
sysfs                        0         0         0   -  /sys
udev                     10240       176     10064   2% /dev
devpts                       0         0         0   -  /dev/pts
/dev/hda1                38856     21129     15721  58% /boot
shm                     252100         0    252100   0% /dev/shm
usbfs                        0         0         0   -  /proc/bus/usb
binfmt_misc                  0         0         0   -  /proc/sys/fs/binfmt_misc

Можно ли проверить состояние винта без останова системы?

.

А еще посмотрите df -i/
Не знаю, существует ли потенциальный риск окончания инодов на вашей ФС, но у меня когдато кончились на ufs

df -i

Вот:

Файловая система      Инодов   Испол   Своб  Исп % смонтирована на
/dev/hda3                  0       0       0    -  /
udev                   63025     778   62247    2% /dev
/dev/hda1              10040      25   10015    1% /boot
shm                    63025       1   63024    1% /dev/shm

у меня на hda3 ReiserFS, там вроде айноды не используются, поэтому и 0 стоит.

ClearKbdBuf написал(а): В

ClearKbdBuf написал(а):
В сислоге основная часть сообщений идут от нагиоса.
При этом меня смутило то, что сислог пытается отправить почту:

May 22 15:01:18 officemanager sSMTP[13471]: Unable to locate mail
May 22 15:01:18 officemanager sSMTP[13471]: Cannot open mail:25

Таких сообщений очень много. Мож в этом дело?
Есть ли возможность запретить ему делать это?

Если пытается отправить - значит есть, что сказать! :)
Запретить нельзя, да и зачем?! Лучше в /etc/hosts пропишите правильный mail.

ClearKbdBuf написал(а):
Что касается дискового пространства то, место вроде есть:
...
Можно ли проверить состояние винта без останова системы?

sys-apps/smartmontools

Спасибо

У меня на работе такая беда

У меня на работе такая беда была..
И если это началось, то дальше будет хуже.

мои советы:
- чеки в нагиос запускать по nrpe (если еще не делаешь так) - Могу поспорить, что это именно его тысячи процессов тебя лоудят.
- поставить на каждую задачу по виртуальной машине. будешь знать, что тебя тормозит.
- вынести cacti (на сколько я понял там тоже 1.5к хостов) на отдельный диск.
- увеличить число каталогов в сквиде. И тоже отдельный диск по возможности.

P.S. htop, iotop тебе в руки

Olek написал(а): У меня на

Olek написал(а):
У меня на работе такая беда была..
И если это началось, то дальше будет хуже.

мои советы:
- чеки в нагиос запускать по nrpe (если еще не делаешь так) - Могу поспорить, что это именно его тысячи процессов тебя лоудят.
- поставить на каждую задачу по виртуальной машине. будешь знать, что тебя тормозит.
- вынести cacti (на сколько я понял там тоже 1.5к хостов) на отдельный диск.
- увеличить число каталогов в сквиде. И тоже отдельный диск по возможности.

P.S. htop, iotop тебе в руки

- нагиос не тормозит, вренее систему нагружает, но вмеру;
- в кактусе мониторятся только магистральные каналы;
- после устранения проблемыы (см. выше) сквид перестал тормозить.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".