Jeśli użyję „top”, mogę zobaczyć, który procesor jest zajęty i który proces wykorzystuje cały mój procesor.
Jeśli użyję "iostat -x", widzę, który dysk jest zajęty.
Ale jak sprawdzić, który proces wykorzystuje całą przepustowość dysku?
Jeśli użyję „top”, mogę zobaczyć, który procesor jest zajęty i który proces wykorzystuje cały mój procesor.
Jeśli użyję "iostat -x", widzę, który dysk jest zajęty.
Ale jak sprawdzić, który proces wykorzystuje całą przepustowość dysku?
Odpowiedzi:
Szukasz iotop
(zakładając, że masz jądro> 2.6.20 i Python 2.5). W przeciwnym razie chcesz podłączyć się do systemu plików. Polecam ten pierwszy.
iotop
wydaje się pokazywać przepustowość we / wy, a nie liczbę operacji we / wy zużywanych przez procesy. To nie jest zbyt istotne. Proces wykonujący wiele małych zapisów + synchronizacja zużyje więcej pojemności IO dysku niż proces zapisujący dużą ciągłą partię danych z dużą szybkością.
[jdb2/nvme0n1p1]
w iotop, ale miałem szczęście włączając / proc / sys / vm / block_dump i porównując dane wyjściowe do zdrowego / stabilnego systemu lxadm.com/Simple_filesystem_read/write_tracing_with_/proc/sys/ ... Pomogło to znaleźć kontener docker, który nieustannie generował żądania kubectl, wyczerpując kredyty serii EBS z wpisami w /home/spinnaker/.kube/cache/discovery/.../serverresources.json
. Po zawężeniu rzeczy do nazwy użytkownika / procesu coś takiego iotop -atku systemd-network | grep kubectl
może również pomóc
Aby dowiedzieć się, które procesy w stanie „D” (oczekujące na odpowiedź dysku) są obecnie uruchomione:
while true; do date; ps aux | awk '{if($8=="D") print $0;}'; sleep 1; done
lub
watch -n1 -d "ps axu | awk '{if (\$8==\"D\") {print \$0}}'"
Wed Aug 29 13:00:46 CLT 2012
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:47 CLT 2012
Wed Aug 29 13:00:48 CLT 2012
Wed Aug 29 13:00:49 CLT 2012
Wed Aug 29 13:00:50 CLT 2012
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:51 CLT 2012
Wed Aug 29 13:00:52 CLT 2012
Wed Aug 29 13:00:53 CLT 2012
Wed Aug 29 13:00:55 CLT 2012
Wed Aug 29 13:00:56 CLT 2012
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:57 CLT 2012
root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush]
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:58 CLT 2012
root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush]
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:59 CLT 2012
root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush]
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:00 CLT 2012
root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush]
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:01 CLT 2012
root 302 0.0 0.0 0 0 ? D May28 3:07 \_ [kdmflush]
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:02 CLT 2012
Wed Aug 29 13:01:03 CLT 2012
root 321 0.0 0.0 0 0 ? D May28 4:25 \_ [jbd2/dm-0-8]
Jak widać z wyniku, jdb2 / dm-0-8 (proces dziennika ext4) i kdmflush nieustannie blokują Linuksa.
Aby uzyskać więcej informacji, pomocny może być ten adres URL: Linux Wait-IO Problem
atop działa również dobrze i łatwo się instaluje nawet na starszych systemach CentOS 5.x, na których nie można uruchomić iotop. Kliknij, d
aby wyświetlić szczegóły dysku w ?
celu uzyskania pomocy.
ATOP - mybox 2014/09/08 15:26:00 ------ 10s elapsed
PRC | sys 0.33s | user 1.08s | | #proc 161 | #zombie 0 | clones 31 | | #exit 16 |
CPU | sys 4% | user 11% | irq 0% | idle 306% | wait 79% | | steal 1% | guest 0% |
cpu | sys 2% | user 8% | irq 0% | idle 11% | cpu000 w 78% | | steal 0% | guest 0% |
cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu001 w 0% | | steal 0% | guest 0% |
cpu | sys 1% | user 1% | irq 0% | idle 99% | cpu003 w 0% | | steal 0% | guest 0% |
cpu | sys 0% | user 1% | irq 0% | idle 99% | cpu002 w 0% | | steal 0% | guest 0% |
CPL | avg1 2.09 | avg5 2.09 | avg15 2.09 | | csw 54184 | intr 33581 | | numcpu 4 |
MEM | tot 8.0G | free 81.9M | cache 2.9G | dirty 0.8M | buff 174.7M | slab 305.0M | | |
SWP | tot 2.0G | free 2.0G | | | | | vmcom 8.4G | vmlim 6.0G |
LVM | Group00-root | busy 85% | read 0 | write 30658 | KiB/w 4 | MBr/s 0.00 | MBw/s 11.98 | avio 0.28 ms |
DSK | xvdb | busy 85% | read 0 | write 23706 | KiB/w 5 | MBr/s 0.00 | MBw/s 11.97 | avio 0.36 ms |
NET | transport | tcpi 2705 | tcpo 2008 | udpi 36 | udpo 43 | tcpao 14 | tcppo 45 | tcprs 1 |
NET | network | ipi 2788 | ipo 2072 | ipfrw 0 | deliv 2768 | | icmpi 7 | icmpo 20 |
NET | eth0 ---- | pcki 2344 | pcko 1623 | si 1455 Kbps | so 781 Kbps | erri 0 | erro 0 | drpo 0 |
NET | lo ---- | pcki 423 | pcko 423 | si 88 Kbps | so 88 Kbps | erri 0 | erro 0 | drpo 0 |
NET | eth1 ---- | pcki 22 | pcko 26 | si 3 Kbps | so 5 Kbps | erri 0 | erro 0 | drpo 0 |
PID RDDSK WRDSK WCANCL DSK CMD 1/1
9862 0K 53124K 0K 98% java
358 0K 636K 0K 1% jbd2/dm-0-8
13893 0K 192K 72K 0% java
1699 0K 60K 0K 0% syslogd
4668 0K 24K 0K 0% zabbix_agentd
To wyraźnie pokazuje, że winowajcą jest Java pid 9862.
TL; DR
Jeśli możesz skorzystać iotop
, zrób to. W przeciwnym razie może to pomóc.
Użyj top
, a następnie użyj tych skrótów:
d 1 = set refresh time from 3 to 1 second
1 = show stats for each cpu, not cumulated
Musi to pokazywać wartości > 1.0 wa
dla co najmniej jednego rdzenia - jeśli nie ma oczekujących na dysk, po prostu nie ma obciążenia we / wy i nie trzeba szukać dalej. Zwykle rozpoczynają się znaczące obciążenia > 15.0 wa
.
x = highlight current sort column
< and > = change sort column
R = reverse sort order
Wybierz „S”, kolumnę stanu procesu. Odwróć kolejność sortowania, aby procesy „R” (uruchomione) były wyświetlane na górze. Jeśli potrafisz dostrzec procesy „D” (oczekujące na dysk), masz wskaźnik, jaki może być twój winowajca.
Użytkownicy KDE mogą użyć polecenia „ctrl-esc”, aby wywołać monitor aktywności systemu, a tam są wykresy aktywności we / wy z identyfikatorem i nazwą procesu.
Nie mam uprawnień do przesyłania obrazu ze względu na „status nowego użytkownika”, ale możesz sprawdzić poniższe zdjęcie. Ma kolumnę do odczytu i zapisu we / wy.
iotop z flagą -a:
-a, --accumulated show accumulated I/O instead of bandwidth