Linux IO dosya başına izleme?


29

CentOS'ta dosya başına disk IO'yu izlemek için bir yardımcı program veya işlemle ilgileniyorum .

Win2008'de resmon yardımcı programı bu türden bir incelemeye izin verir, ancak bulduğum Linux yardımcı programlarının hiçbiri bunu yapmaz (iostat, iotop, dstat, nmon).

Veritabanı sunucularındaki IO darboğazlarını izlemeye olan ilgim. MSSQL ile, hangi dosyaların / dosya alanlarının en çok etkilendiğini bilmek için bilgilendirici bir tanılama buldum.


2
Belki Linux Performans Analizi ve Araçları: Brendan Gregg'in SCaLE 11x'teki Konuşması size yardımcı olabilir; 72/115 no.lu slayta bakınız.
Cristian Ciupitu

1
Bu mümkünse, çoğu dosyanın pagecache'de eşlendiğini unutmayın; böylece sayılarınız sayfa baytının ne olduğuna ve diskte ne olduğuna bağlı olarak her yerde olabilir.
Matthew Ife

@Matt Ama çalışan bir cevap ile!
ewwhite'de

Yanıtlar:


18

SystemTap muhtemelen en iyi seçenektir.

İotime.stp örneğindeki çıktı şöyle görünür:

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

Dezavantajı (öğrenme eğrisinden başka) üretim sisteminde mümkün olmayan çekirdek hata ayıklamasını yüklemeniz gerekmesidir. Bununla birlikte, bir geliştirme sistemi üzerinde bir modül derlediğiniz çapraz üretim araçlarına başvurabilir ve bu .ko'yu üretim sisteminde çalıştırabilirsiniz .

Ya da sabırsızsanız, Bölüm 4'e bakınız . Yeni başlayanlar kılavuzundaki Faydalı SystemTap Scriptleri .


17

SystemTap * komut dosyası:

#!/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)
}

Çıktı şöyle görünür:

[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

Veya yalnızca bağlantı noktasındaki yolu görüntülemeyi seçerseniz:

[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)

Sınırlamalar / hatalar:

  • mmap G / Ç çünkü görünmüyor esaslı devnameDİR"N/A"
  • dosyalar tmpfs çünkü görünmüyor devnameolduğunu"N/A"
  • okurların önbellekten olup olmadığının veya yazmaların arabelleğe alması önemli değil

Matthew Ife'in programlarının sonuçları :

  • için mmaptest ozel:

     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
    
  • paylaşılan mmaptest için :

     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
    
  • için diotest (doğrudan G / Ç):

     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
    

* RHEL 6 veya eşdeğeri için hızlı kurulum talimatları: yum install systemtapvedebuginfo-install kernel


İşte orada etkileyici bir sistem. Çok yönlülüğünün mükemmel bir kanıtı.
Matthew Ife

Bu ölçü, G / Ç'yi ve asenkron G / Ç'yi yönlendirir mi? (io_submit kullanarak, posix değil)
Matthew Ife

@Mlfe: teşekkürler! Bir not olarak, senaryoyu yazarken pv'de küçük bir hata bulmayı başardım ve SystemTap'ta ( task_dentry_path) :-) başka bir hata bulmayı başardım :-) Bu G / Ç hakkında hiçbir fikrim yok; örnek bir program. Örneğin mmap'i test etmek için Python kullandım . dd iflag=direct oflag=directortaya çıktı.
Cristian Ciupitu,

2
Bunu mmap için deneyin: gist.github.com/anonymous/7014284 Bahse girerim özel eşlemeler ölçülmez ancak paylaşılanlar .. ..
Matthew Ife

2
Heres doğrudan G /
Matthew Ife

9

Aslında bunun için kullanmak blktraceisterdin. Seekwatcher ve blktrace ile Linux IO'yu Görselleştirme konusuna bakın .

Yakında örneklerimden birini gönderebilir miyim bakalım.


Düzenle:

Linux dağıtımından bahsetmiyorsunuz, ama belki RHEL benzeri bir sistem kullanıyorsanız, Linux veya hatta System Tap'ta bir dtrace betiği için iyi bir durumdur .


2
Teşekkürler, iyi bir şey ve noktaya çok yakın, ancak ayrıntılı blok katmanı bilgisi sağlıyor, VFS soyutlama katmanı üzerinde çalışan bir şeye ihtiyacım var.
GioMac

Bunu çalıştırmak için bazı systemtap komut dosyalarını denemeye başladım. Sunucu çöktü çünkü başarısız oldum. Bu bilgiyi Solaris'teki Dtrace'de bulabilirim. Bugün Linux ile deneyeceğim.
ewwhite

4

Bunu bildiğim tek araç G / Ç etkinliğini dosyaya göre izleyebiliyor inotifywatch. inotify-toolsPaketin bir parçası . Ne yazık ki, sadece size operasyon sayıları verir.


4

yüksek IO'ya katkıda bulunan işlemlerin PID'lerini almak için iotop kullanın

Oluşturduğunuz PID'ye karşı strace çalıştırdığınızda, belirli bir işlemle hangi dosyalara erişildiğini göreceksiniz.

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

strace, sistemler ve erişilen dosyalar hakkında bilgi verecek, kullanımla ilgili ayrıştırma ve istatistik elde etmek çok zor olacak ...
GioMac

1
Bunu deneyeyim dedim. Veri ALOT oluşturur. Ve ctrl + c olduğunda işlemi çökertebilir. Oldukça tehlikeli görünüyor.
Matt

4

Sonunda bunun için Sysdig kullandım


Nasıl Yapılır: sysdig'i kurun , çalıştırın csysdig, F2 tuşuna basın ve Filesgörünümü seçin . Erişilen dosyaların üst kısmını OPS sütunu ile göreceksiniz (F9 tuşlarına basılarak değiştirilebilir).
catpnosis

csysdig -v filesdoğrudan "Dosyalar" görünümüne gider
Gert van den Berg

2

Yanlış soruyu sormuş olabileceğini savunuyorum. Eğer darboğazlar arıyorsanız, diskinizde neler olduğunu görmek de aynı derecede önemli olabilir. db'ler, özellikle sadece birkaç iğiniz varsa, verimi önemli ölçüde azaltabilen rastgele giriş / çıkış işlemleri yapmakla ünlüdür.

Daha ilginç olan, disklerde uzun bekleme süreleri olup olmadığını görmek. Bunu disk disk ile kişisel disk performans istatistiklerini gösterecek olan “collectl -sD” komutu ile yapabilirsiniz. Are - bir üst benzeri yardımcı programa dönüştürmek için ev. Çok sayıda disk varsa, colmux: colmux -command "-sD" ile çalıştırın ve birden fazla sistemde bile seçtiğiniz bir sütuna göre sıralamanıza izin verecektir.


Disk perspektifinden sana katılmıyorum. Bazı bilgiler edinebileceğim bir veritabanı veri alanları verileri, dizinleri, günlükleri vb. Bölümlemek için kullanıldığında, ancak kaynaklar sınırlı olduğunda paylaşılan disklere monte edildiğinde - örneğin geliştirme sunucuları. İdeal olarak, bu dosya alanlarının her biri ayrı birimlerde olacaktı, bu nedenle IO'ya disk perspektifinden bakmak yeterli olacaktır - bu nedenle tüm izleme yardımcı programlarının dosya tabanlı değil de disk olmasının nedeni budur.
kermatt

Doğru soru; amaç, "bütün bu G / Ç'lerin hangi tabloda gerçekleştiğini" bulmaktır ve çoğu veritabanında bir tablo bir veya daha fazla dosyadır. Herhangi bir disk üzerinde birçok dosya olacak ve bunlardan hangisinin sıcak nokta olduğunu belirlemek yararlı bir veritabanı ayarlama girişi.
Greg Smith,

2

Blok aygıtı başına (/ proc / diskstats ile) ve işlem başına (io üzerinden muhasebe /proc/$PID/ioveya görev noktaları ) g / ç izleyebilirsiniz , ancak dosya başına yapmanın bir yolunu bilmiyorum.


0

Olabilir İnotify çözmek bu çözecektir çözecek.

Inotify API, dosya sistemi olaylarını izlemek için bir mekanizma sağlar. Inotify, tek tek dosyaları izlemek veya dizinleri izlemek için kullanılabilir. Bir dizin izlendiğinde, inotify, dizinin kendisi ve dizindeki dosyalar için olayları döndürür.

İnotify ile Dosya Sistemi Etkinliğini İzleme

Referans belirtmek


Bu dosya üzerinde yapılan çağrıları sağlayabilir, ancak ne kadar ödeme yaptığını, yazmanın ne kadar büyük olduğunu, nerede ve ne kadar sürdüğünü keşfetmeye yardımcı olacak çok az şey sunar.
Matthew Ife

Soru, süreç hakkında soru sormuyor (muhtemelen başka yollarla da keşfedilebilir lsof)
Gert van den Berg

0

Buradaki cevaplarda birçok iyi bilgi olmasına rağmen, gerçekten uygulanabilir olup olmadığını merak ediyorum.

10 gigabaytlık dosyalardan bahsediyorsanız, sürekli olarak yazılıyorsa, o zaman sürekli eklenmiş günlük dosyaları veya benzeri olmadıkça (bu durumda sadece dosya boyutlarını izleyin), dosyaların büyük olasılıkla mmap edilmesi . Bu durumda, en iyi cevap çoğu çözüme bakmayı bırakmanız olabilir. Daha sonra önerilen başka herhangi bir çözümden sormanız gereken ilk şey "mmap ile çalışıyor" dır, çünkü çoğu zaman yapmazlar. Ancak, sorunu bir dosyayı izlemek yerine bir blok cihazı izlemeye dönüştürebilirsiniz.

Bir program mmap'd dosyasından bir sayfa sorduğunda, sadece sanal bellekteki bir konuma işaret ediyor. Bu sayfa zaten bellekte olabilir veya olmayabilir. Değilse, o zaman diskten yüklenmekte olan sayfayı tetikleyen, ancak belirli bir uygulama işlemine veya belirli bir dosyaya kolayca bağlanmayan sanal bellek sistemi içinde gerçekleşen bir sayfa hatası oluşturur. Benzer şekilde, uygulamanız bir mmap sayfasını güncellediğinde, bayraklara bağlı olarak, diske hemen yazmayı tetiklemeyebilir ve bazı durumlarda hiç diske gitmeyebilir (muhtemelen en son merak ettiğiniz davalar bu değildir. içinde).

Mmap'd dosyaları için düşünebildiğim en iyi şey, eğer sizin için uygunsa, ilgilendiğiniz her dosyayı ayrı bir cihaza koymak ve kullanım bilgilerinizi toplamak için cihaz istatistiklerini kullanmaktır. Bunun için Lvm bölümlerini kullanabilirsiniz. Bağlama bağlantısı yeni bir blok aygıtı oluşturmadığı için çalışmaz.

Dosyalarınızı ayrı blok cihazlarda bulunduktan sonra / sys / block / * veya / proc / diskstats'tan istatistik alabilirsiniz.

Bunu bir üretim sunucusuna tanıtmak çok rahatsız edici olabilir, ancak belki de bundan faydalanabilirsiniz.

Dosyalar eşleştirilmezse, evet, buradan diğer çözümlerden birini seçebilirsiniz.


Lütfen dikkatlice okuyunuz, blok seviyesi istatistiklerine ihtiyacım yok :)
GioMac

Doğru, ancak istediğiniz istatistik türü mmapped dosyalar için mümkün değildir, bu nedenle buna karşı koşarsanız, cihaz başına bir dosya kullanarak ve cihazınızı okuyarak dosyalar hakkında istatistikler elde etmenin mümkün bir yolunu sunar. cihaz istatistikleri.
mc0e

-1

Geçenlerde collectl ile uğraşıyordum , harika bir araç gibi görünüyor ve kurulumu oldukça zor. En ilginç olanı, IO darboğazlarının sorumlu işleminin hangisi olduğunu öğrenmenizdir. Collectl'i okumanızı tavsiye ederim , faydalı olabilir.


1
collectl dosya başına izlemiyor, işlem başına çalışıyor
Greg Smith


-2

İotop'un Linux'ta IO üzerindeki darboğazları belirlemek için en iyi araçlardan biri olduğunu düşünüyorum.


3
-1 iotopdosya başına
izlemez,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.