Monitorowanie IO systemu Linux na plik?


29

Interesuje mnie narzędzie lub proces monitorowania IO dysku według pliku w CentOS.

W Win2008 narzędzie resmon pozwala na tego rodzaju drążenie, ale żadne z narzędzi Linuksa, które znalazłem, nie robi tego (iostat, iotop, dstat, nmon).

Moje zainteresowanie monitorowaniem wąskich gardeł we / wy na serwerach baz danych. W przypadku MSSQL znalazłem pouczającą diagnostykę, aby dowiedzieć się, które pliki / przestrzenie plików są najbardziej dotknięte.



1
Jeśli jest to możliwe, zwróć uwagę, że większość plików jest mapowana do pamięci podręcznej, aby Twoje liczby mogły być wszędzie w zależności od tego, jakie bajty są w pamięci podręcznej i co jest na dysku.
Matthew Ife,

@Matt Ale z działającą odpowiedzią!
ewwhite

Odpowiedzi:


18

SystemTap jest prawdopodobnie najlepszą opcją.

Oto jak wygląda wyjście z przykładu iotime.stp :

825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11

Wadą (oprócz krzywej uczenia się) jest to, że będziesz musiał zainstalować debugowanie jądra , co może nie być możliwe w systemie produkcyjnym. Można jednak skorzystać z instrumentacji krzyżowej, w której kompiluje się moduł w systemie programistycznym i uruchamia ten plik .ko w systemie produkcyjnym.

Lub jeśli jesteś niecierpliwy, spójrz na Rozdział 4. Przydatne skrypty SystemTap z przewodnika dla początkujących.


17

Skrypt SystemTap * :

#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
#   ./monitor-io.stp name-of-the-program

global program_name = @1

probe begin {
  printf("%5s %1s %6s %7s %s\n",
         "PID", "D", "BYTES", "us", "FILE")
}

probe vfs.read.return, vfs.write.return {
  # skip other programs
  if (execname() != program_name)
    next

  if (devname=="N/A")
    next

  time_delta = gettimeofday_us() - @entry(gettimeofday_us())
  direction = name == "vfs.read" ? "R" : "W"

  # If you want only the filename, use
  // filename = kernel_string($file->f_path->dentry->d_name->name)
  # If you want only the path from the mountpoint, use
  // filename = devname . "," . reverse_path_walk($file->f_path->dentry)
  # If you want the full path, use
  filename = task_dentry_path(task_current(),
                              $file->f_path->dentry,
                              $file->f_path->mnt)

  printf("%5d %1s %6d %7d %s\n",
         pid(), direction, $return, time_delta, filename)
}

Dane wyjściowe wyglądają następująco:

[root@sl6 ~]# ./monitor-io.stp cat
PID D  BYTES      us FILE
3117 R    224       2 /lib/ld-2.12.so
3117 R    512       3 /lib/libc-2.12.so
3117 R  17989     700 /usr/share/doc/grub-0.97/COPYING
3117 R      0       3 /usr/share/doc/grub-0.97/COPYING

Lub jeśli zdecydujesz się wyświetlać tylko ścieżkę z punktu montowania:

[root@f19 ~]# ./monitor-io.stp cat
  PID D  BYTES      us FILE
26207 R    392       4 vda3,usr/lib64/ld-2.17.so
26207 R    832       3 vda3,usr/lib64/libc-2.17.so
26207 R   1758       4 vda3,etc/passwd
26207 R      0       1 vda3,etc/passwd
26208 R    392       3 vda3,usr/lib64/ld-2.17.so
26208 R    832       3 vda3,usr/lib64/libc-2.17.so
26208 R  35147      16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R      0       2 vdb7,ciupicri/doc/grub2-2.00/COPYING

[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

Ograniczenia / błędy:

  • We / wy oparte na mmap nie pojawia się, ponieważ devnamejest"N/A"
  • pliki na tmpfs nie pojawiają się, ponieważ devnamejest"N/A"
  • nie ma znaczenia, czy odczyty pochodzą z pamięci podręcznej, czy zapisy są w buforze

Wyniki dla programów Matthew Ife :

  • dla mmaptest private:

     PID D  BYTES      us FILE
    3140 R    392       5 vda3,usr/lib64/ld-2.17.so
    3140 R    832       5 vda3,usr/lib64/libc-2.17.so
    3140 W     23       9 N/A,3
    3140 W     23       4 N/A,3
    3140 W     17       3 N/A,3
    3140 W     17     118 N/A,3
    3140 W     17     125 N/A,3
    
  • dla mmaptest udostępnionego:

     PID D  BYTES      us FILE
    3168 R    392       3 vda3,usr/lib64/ld-2.17.so
    3168 R    832       3 vda3,usr/lib64/libc-2.17.so
    3168 W     23       7 N/A,3
    3168 W     23       2 N/A,3
    3168 W     17       2 N/A,3
    3168 W     17      98 N/A,3
    
  • dla diotestu (bezpośrednie I / O):

     PID D  BYTES      us FILE
    3178 R    392       2 vda3,usr/lib64/ld-2.17.so
    3178 R    832       3 vda3,usr/lib64/libc-2.17.so
    3178 W     16       6 N/A,3
    3178 W 1048576     509 vda3,var/tmp/test_dio.dat
    3178 R 1048576     244 vda3,var/tmp/test_dio.dat
    3178 W     16      25 N/A,3
    

* Instrukcje szybkiej konfiguracji dla RHEL 6 lub równoważnego: yum install systemtapidebuginfo-install kernel


To całkiem imponujący system. Doskonały dowód na jego wszechstronność.
Matthew Ife

Czy to mierzy bezpośrednie I / O i asynchroniczne I / O? (używając io_submit, a nie posix)
Matthew Ife

@Mlfe: dzięki! Na marginesie, podczas pisania skryptu udało mi się odkryć malutki błąd w pv i inny w SystemTap ( task_dentry_path) :-) Nie mam pojęcia o tym I / O, ale mogę go przetestować, jeśli wydasz mi polecenie lub przykładowy program. Na przykład użyłem Pythona do przetestowania mmapa. dd iflag=direct oflag=directpokazuje się.
Cristian Ciupitu

2
Wypróbuj to dla mmap: gist.github.com/anonymous/7014284 Założę się , że prywatne mapowania nie są mierzone, ale wspólne są…
Matthew Ife

2
Oto bezpośredni test IO: gist.github.com/anonymous/7014604
Matthew Ife

9

Naprawdę chcesz do tego użyć blktrace. Zobacz Wizualizacja Linux IO za pomocą Seekwatchera i blktrace .

Zobaczę, czy wkrótce mogę opublikować jeden z moich przykładów.


Edytować:

Nie wspominasz o dystrybucji Linuksa, ale być może jest to dobry przypadek skryptu dtrace w systemie Linux, a nawet System Tap , jeśli używasz systemu podobnego do RHEL.


2
Dzięki, dobrze i bardzo blisko do sedna, ale zapewnia szczegółowe informacje o warstwie blokowej, potrzebuję czegoś, co działa na warstwie abstrakcji VFS.
GioMac,

Zacząłem próbować uruchomić niektóre skrypty systemowe. Nie udało mi się, ponieważ serwer się zawiesił. Mogę uzyskać te informacje w Dtrace na Solarisie. Spróbuję dziś z Linuksem.
ewwhite

4

Jedyne znane mi narzędzie, które może monitorować aktywność we / wy według plików, to inotifywatch. To część inotify-toolspakietu. Niestety daje tylko liczbę operacji.


4

użyj iotop, aby uzyskać PID procesów, które przyczyniają się do wysokiego IO

uruchom strace w stosunku do wygenerowanego PID, zobaczysz, które pliki są uzyskiwane przez dany proces

strace -f -p $PID -e trace=open,read,write

strace dostarczy informacji o wywołaniach systemowych i dostępie do plików, bardzo trudno będzie parsować i uzyskać statystyki dotyczące użycia ...
GioMac

1
Myślałem, że spróbuję tego. Generuje dużo danych. I może zawiesić proces, gdy ctrl + c. Wydaje się to dość niebezpieczne.
Matt


2

Twierdzę, że mogłeś zadać niewłaściwe pytanie. jeśli szukasz wąskich gardeł we / wy, równie ważne może być zobaczenie, co dzieje się na dysku. db są znane z robienia losowych operacji we / wy, co może znacznie zmniejszyć przepustowość, szczególnie jeśli masz tylko kilka wrzecion.

ciekawsze może być sprawdzenie, czy masz długi czas oczekiwania na samych dyskach. możesz to zrobić za pomocą polecenia collectl za pomocą polecenia „collectl -sD”, które wyświetli statystyki wydajności poszczególnych dysków. Czy - home, aby zmienić go w narzędzie podobne do najlepszych? Jeśli w grę wchodzi wiele dysków, uruchom ją za pomocą colmux: colmux -command "-sD", a pozwoli ci to sortować według wybranej kolumny, nawet w wielu systemach.


Nie zgadzam się z tobą z perspektywy dysku. Mogę uzyskać wgląd w to, kiedy obszary plików bazy danych są używane do partycjonowania danych, indeksów, dzienników itp., Ale montowane na dyskach współdzielonych, gdy zasoby są ograniczone - na przykład serwery programistyczne. Idealnie byłoby, gdyby każda z tych przestrzeni plików znajdowała się na osobnych woluminach, dlatego odpowiednie byłoby sprawdzenie IO z perspektywy dysku - prawdopodobnie dlatego wszystkie narzędzia monitorowania są oparte na dyskach, a nie na plikach.
kermatt

To właściwe pytanie; celem jest próba ustalenia, „do której tabeli zdarza się to wszystko we / wy?”, aw większości baz danych tabela zawiera jeden lub więcej plików. Na każdym dysku znajdzie się wiele plików, a określenie, które z nich są punktami dostępowymi, jest użytecznym wejściem do strojenia bazy danych.
Greg Smith

2

Możesz monitorować operacje wejścia / wyjścia według urządzenia blokowego (przez / proc / diskstats) i według procesu (rozliczanie io przez /proc/$PID/iolub stacje zadań ), ale nie znam sposobu, aby to zrobić dla pliku.


0

Może być inotify rozwiąże problem.

Interfejs API inotify zapewnia mechanizm monitorowania zdarzeń w systemie plików. Inotify może służyć do monitorowania pojedynczych plików lub do monitorowania katalogów. Gdy katalog jest monitorowany, inotify zwróci zdarzenia dla samego katalogu i plików w nim zawartych.

Monitoruj aktywność systemu plików za pomocą inotify

inotify Reference


Może to zapewnić wywołania wykonane w pliku, ale niewiele oferuje, aby dowiedzieć się, co zrobił pid, jak duży był zapis, gdzie i jak długo to trwało.
Matthew Ife,

Pytanie nie pyta o proces (który można odkryć innymi sposobami, na przykład lsof)
Gert van den Berg

0

Chociaż w odpowiedziach jest wiele dobrych informacji, zastanawiam się, czy to rzeczywiście dotyczy?

Jeśli mówisz o plikach o wielkości 10 gigabajtów, ciągle zapisywanych, to chyba że są to pliki dziennika lub podobne, które są stale dołączane (w takim przypadku monitoruj tylko rozmiary plików), najprawdopodobniej pliki są mapowane w mmap . W takim przypadku najlepszą odpowiedzią może być zaprzestanie poszukiwania większości rozwiązań. Pierwszą rzeczą, którą powinieneś następnie zapytać o inne proponowane rozwiązanie, jest „czy to działa z mmap”, ponieważ w większości tak nie jest. Jednak możesz być w stanie przekształcić problem w monitorowanie urządzenia blokowego zamiast monitorowania pliku.

Gdy program prosi o stronę z pliku mmap'd, odnosi się tylko do lokalizacji w pamięci wirtualnej. Ta strona może już nie być w pamięci. JEŚLI tak nie jest, generuje to błąd strony, który powoduje załadowanie strony z dysku, ale dzieje się tak w systemie pamięci wirtualnej, który nie jest łatwo powiązany z konkretnym procesem aplikacji lub z konkretnym plikiem. Podobnie, gdy twoja aplikacja aktualizuje stronę mmap, w zależności od flag, może to nie spowodować natychmiastowego zapisu na dysk, aw niektórych przypadkach może wcale nie przejść na dysk (choć prawdopodobnie te ostatnie nie są przypadkami, które Cię interesują) w).

Najlepsze, co mogę wymyślić dla plików mmap, jeśli jest to dla ciebie opłacalne, to umieszczenie każdego z interesujących plików na osobnym urządzeniu i wykorzystanie statystyk urządzenia do zebrania informacji o użyciu. Możesz do tego użyć partycji lvm. Wiązanie łączenia nie działa jednak, ponieważ nie tworzy nowego urządzenia blokowego.

Gdy masz pliki na osobnych urządzeniach blokowych, możesz uzyskać statystyki z / sys / block / * lub / proc / diskstats

Wprowadzenie tego na serwer produkcyjny może być zbyt destrukcyjne, ale być może możesz z niego skorzystać.

JEŻELI pliki nie są odwzorowane na mma, to tak, możesz wybrać jedno z innych rozwiązań tutaj.


Przeczytaj uważnie, nie potrzebuję statystyk na poziomie bloków :)
GioMac,

Zgadza się, ale rodzaj statystyk, o które prosisz, nie jest możliwy w przypadku plików mapowanych, więc jeśli masz na to ochotę, daje to możliwy sposób uzyskania statystyk dotyczących plików za pomocą jednego pliku na urządzenie i odczytania statystyki urządzenia.
mc0e,

-1

Niedawno majstrowałem przy kolekcjonowaniu , wygląda na świetne narzędzie i dość proste w instalacji. Najciekawsze jest to, że możesz dowiedzieć się, który proces jest odpowiedzialny za wąskie gardła we / wy. Polecam przeczytanie Korzystanie z Collectl , może być przydatne.


1
collectl nie monitoruje pliku, działa na proces
Greg Smith


-2

Myślę, że iotop jest jednym z najlepszych narzędzi w Linuksie do identyfikowania wąskich gardeł w IO.


3
-1 iotopnie monitoruje pliku, działa na proces
dyasny
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.