Ситуация: у меня есть сервер, на котором у нас 2-3 проекта. Не так давно сервер запустился повесить трубку (Мы не могли подключиться к нему по ssh, и подключенным клиентам пришлось ждать 20 минут, пока top не выдаст результаты)
Сегодня рано утром мне удалось выполнить gstat пока он был в этом состоянии и увидел, что он остается на 100% на da0, da0s1 и da0s1f. Я не совсем понимаю, что означают эти идентификаторы, но я понимаю, что некоторые процессы просто убивают HD, бомбардируя его запросами.
Я прошу некоторых предложений. Я не знаю, как найти виновного, и не могу этого предотвратить.
У меня на сервере есть freebsd.
Если ваша версия FreeBSD относительно современная, top имеет -m вариант, который показывает верхние участники ввода / вывода, если вы поставите его с "io"параметр:
top -m io
В этом случае я бы также использовал -S вариант (чтобы показать системные процессы, если один из них виноват). Чтобы лучше себя вести под нагрузкой, я бы использовал -q (чтобы заставить его работать с более высоким приоритетом), и -u (пропустить чтение /etc/passwd, что должно помочь ему загружаться быстрее).
Поскольку бегать так долго top, Я бы сказал, чтобы он отображал только два прохода вывода (-d 2), а затем запустить в пакетном режиме (-b), поэтому он автоматически выйдет.
В первый момент, когда ты бежишь top таким образом, его первая часть вывода будет показывать совокупное количество операций ввода-вывода для ряда процессов довольно далеко назад (может быть, с момента загрузки? Я на самом деле не уверен в этом). На первом экране вы можете увидеть, кто из вас больше всего болтал с течением времени. На втором экране вы можете увидеть самых активных участников разговора за последние две секунды.
Итак, собрав все вместе и запустив find так что происходит фактический ввод-вывод:
# top -S -m io -qu -b -d 2 10
last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:29 11:28:28
125 processes: 2 running, 104 sleeping, 19 waiting
Mem: 96M Active, 668M Inact, 122M Wired, 25M Cache, 104M Buf, 17M Free
Swap: 2048M Total, 96K Used, 2048M Free
PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
11 0 0 81032823 0 0 0 0 0.00% idle: cpu0
39554 105 129857 556534 74894 0 0 74894 13.62% find
39533 105 443603 614796 0 0 0 0 0.00% sshd
36 0 1793393 0 0 0 0 0 0.00% irq23: vr0
24 0 2377710 2680 0 0 0 0 0.00% irq20: atapci0
50 0 533513 3415672 66 345350 0 345416 62.81% syncer
13 0 78651569 7230 0 0 0 0 0.00% swi4: clock sio
5 0 1911601 20905 0 0 0 0 0.00% g_down
4 0 2368511 12100 0 0 0 0 0.00% g_up
37 0 53308 313 0 0 0 0 0.00% acpi_thermal
last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:31 11:28:30
125 processes: 2 running, 104 sleeping, 19 waiting
CPU: 1.9% user, 0.0% nice, 6.0% system, 2.2% interrupt, 89.9% idle
Mem: 96M Active, 671M Inact, 123M Wired, 25M Cache, 104M Buf, 14M Free
Swap: 2048M Total, 96K Used, 2048M Free
PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
11 0 0 1115 0 0 0 0 0.00% idle: cpu0
39554 105 606 651 501 0 0 501 100.00% find
39533 105 616 695 0 0 0 0 0.00% sshd
36 0 1251 0 0 0 0 0 0.00% irq23: vr0
24 0 501 20 0 0 0 0 0.00% irq20: atapci0
50 0 2 2 0 0 0 0 0.00% syncer
13 0 313 3 0 0 0 0 0.00% swi4: clock sio
5 0 501 26 0 0 0 0 0.00% g_down
4 0 501 8 0 0 0 0 0.00% g_up
37 0 0 0 0 0 0 0 0.00% acpi_thermal
Как только вы сузите, какой процесс выполняет весь ввод-вывод, вы можете использовать truss или devel/strace или sysutils/lsof порты, чтобы увидеть, что делают ваши ресурсоемкие процессы. (если ваша система очень загружена, конечно, вы не сможете легко установить порты):
Например, чтобы увидеть, какие файлы и другие ресурсы у меня ntpd процесс использует:
# lsof -p 890
ntpd 890 root cwd VDIR 0,93 1024 2 /
ntpd 890 root rtd VDIR 0,93 1024 2 /
ntpd 890 root txt VREG 0,98 340940 894988 /usr/sbin/ntpd
ntpd 890 root txt VREG 0,93 189184 37058 /libexec/ld-elf.so.1
ntpd 890 root txt VREG 0,93 92788 25126 /lib/libm.so.5
ntpd 890 root txt VREG 0,93 60060 25130 /lib/libmd.so.4
ntpd 890 root txt VREG 0,98 16604 730227 /usr/lib/librt.so.1
ntpd 890 root txt VREG 0,93 1423460 25098 /lib/libcrypto.so.5
ntpd 890 root txt VREG 0,93 1068216 24811 /lib/libc.so.7
ntpd 890 root 0u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 1u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 2u VCHR 0,29 0t0 29 /dev/null
ntpd 890 root 3u unix 0xc46da680 0t0 ->0xc4595820
ntpd 890 root 5u PIPE 0xc4465244 0 ->0xc446518c
ntpd 890 root 20u IPv4 0xc4599190 0t0 UDP *:ntp
ntpd 890 root 21u IPv6 0xc4599180 0t0 UDP *:ntp
ntpd 890 root 22u IPv4 0xc4599400 0t0 UDP heffalump.prv.tycho.org:ntp
ntpd 890 root 23u IPv4 0xc4599220 0t0 UDP ns0.prv.tycho.org:ntp
ntpd 890 root 24u IPv4 0xc45995c0 0t0 UDP imap.prv.tycho.org:ntp
ntpd 890 root 25u IPv6 0xc4599530 0t0 UDP [fe80:4::1]:ntp
ntpd 890 root 26u IPv6 0xc45993b0 0t0 UDP localhost:ntp
ntpd 890 root 27u IPv4 0xc4599160 0t0 UDP localhost:ntp
ntpd 890 root 28u rte 0xc42939b0 0t0
... и какие системные вызовы он делает (обратите внимание, что это может быть ресурсоемким):
# truss -p 890
SIGNAL 17 (SIGSTOP)
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
^C
sysutils/strace похоже на truss, но вам понадобится /proc файловая система смонтирована:
# strace -p 890
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file
# grep ^proc /etc/fstab
proc /proc procfs rw,noauto 0 0
# mount /proc
# mount | grep /proc
procfs on /proc (procfs, local)
... и тогда он будет работать:
# strace -p 890
Process 890 attached - interrupt to quit
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10) = -1 (errno 4)
select(29, [?], NULL, NULL, NULL) = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10) = -1 (errno 4)
select(29, [?], NULL, NULL, NULL^C <unfinished ...>
Process 890 detached
Удачи - дайте нам знать, что вы обнаружите! Как только вы определите процесс (ы), я смогу вам помочь.
РЕДАКТИРОВАТЬ: Обратите внимание, что бег lsof , truss и strace сами могут быть интенсивными. Я сделал несколько незначительных обновлений, чтобы уменьшить их влияние. Кроме того, если процесс быстро рождает много детей, вам, возможно, придется сказать truss или strace следить за дочерними процессами с помощью -f аргумент.
Через некоторое время я нашел настоящая проблема. Как я думал в последнем комментарии, это проблема нехватки памяти.
Виновником был ZEO сервер для ZODB. Он очень полагался на кеш ввода-вывода системного диска, и это приводило к обратным результатам, когда свободной памяти было меньше 500 МБ он начал замедляться и продолжаться 300 МБ он просто так много использовал диск, что система перестала отвечать, и даже некоторые службы начали отказывать (например, sshd).
После изменения структуры кеша и освобождения до 2 ГБ свободной памяти проблема устранена.