Linux I / O gecikmesinde hata ayıklama

Yönettiğim birkaç Linux sisteminde bazı G / Ç sorunları yaşıyorum. Süreçlerin dosyalarda open (), unlink () veya close () gibi basit sistem çağrılarında genellikle birkaç saniyeye kadar bloke edildiğini gösterirler (bu bir sorundur, çünkü bazı programların çalışması için oldukça düşük G / Ç gecikmesi gerekir uygun şekilde). Söz konusu sistemlerin bir miktar I / O yükü yaşadığı doğrudur, ancak bu kadar büyük gecikme sürelerini haklı çıkarmanın yeterli olacağını düşünmüyorum. Bazen, aramaların tamamlanması 15 saniyeden uzun sürebilir (daha sık olarak 1 veya 2 veya 3 saniye sürebilir).

Sorum şu: Bunun neden olduğunu nasıl öğrenebilirim? İstediğim şey bana, söz konusu işlemlerin çekirdekte neyle engellendiğini ve üzerinde uyudukları şeyin neden meşgul olduğunu, neler olduğunu ve bu gibi şeyleri anlatabilecek bir araç. Böyle bir araç var mı veya ne olduğunu ayıklamaya çalışmanın başka bir yolu var mı?

Aslında ne olarak herhangi bir ipucu var Alternatif olarak, eğer tabii ki, bir olay, nasıl önlenebilir?

Kayıt için kullandığım dosya sistemi XFS'dir.

Şimdi zamanında, bunu kendim çözmeyi başardım, böylece en azından gelecek nesiller için kendim takip edebilirim.

Ne yazık ki, çekirdek yükseltmesinde orijinal sorunu kaybettim, ancak yerine yeni bir tane kazandım, performansta daha da kötüsü ve izlemesi zor. Bulduğum teknikler şunlardı:

Her şeyden önce, blktrace/ blkparseoldukça yararlı bulduğum bir araçtır. Tek tek G / Ç isteklerinin ilerlemesinin, isteği gönderen süreç gibi birçok yararlı ayrıntıyla izlenmesini sağlar. Çıktıyı koymak yararlıdır tmpfs, böylece izin depolanmasının işlenmesi izlemeye başlamaz.

Ancak bu şimdiye kadar yardımcı oldu, bu yüzden daha fazla hata ayıklama işlevselliğine sahip bir çekirdek derledim. Özellikle, ftraceçekirdek alanı içindeki zayıf performans gösteren süreci izlememe, ne yaptığını ve nerede engellediğini görmeme izin verdiğinden oldukça yararlı buldum . Bir hata ayıklama çekirdeğinin derlenmesi , en azından daha basit durumlarda, bir işlemin çekirdek içinde ne yaptığını görmenin daha kolay bir yolu olarak da çalışabilen çalışma WCHANçıktısı da sağlar ps.

Ayrıca LatencyTop'un yararlı olmasını umuyordum , ancak oldukça buggy buldum ve aynı zamanda maalesef gerçekten "çok yüksek düzey" olan gecikme nedenlerini de gösterdi.

Ayrıca, iostatiçeriği /sys/block/$DEVICE/statçok yakın aralıklarla görüntülemek daha yararlı buldum , sadece şöyle:

while :; do cat /sys/block/sda/stat; sleep .1; done

Dosyanın Documentation/iostats.txtbiçimi için çekirdek kaynak ağacına bakın stat. Yakın aralıklarla izlemek, G / Ç patlamalarının ve bu gibi şeylerin tam zamanlamasını ve boyutunu görmemi sağladı.

Sonunda, çekirdek yükseltmesinden sonra yaşadığım sorunun Linux 3.0'da tanıtılan ve benim durumumda Berkeley DB'nin mmap'lerindeki sayfaları kirletirken uzun süre durmasına neden olan kararlı sayfalardan kaynaklandığını öğrendim. bölge dosyaları. Bu özelliği düzeltmek mümkün gibi görünse de, neden olduğu sorunların Linux 3.9'da düzeltilmiş olabileceği halde , bölge dosyalarını farklı bir dizine koymamı sağlamak için Berkeley DB'yi yamalayarak şimdiye kadar yaşadığım en kötü sorunu çözdüm. (benim durumumda /dev/shm) sorundan tamamen kurtulmama izin verdi.

Deneyimlerime göre, gizemli sistem performansı sorunlarını izlemek için yükleyebileceğiniz en basit ve en ayrıntılı istatistik aracı http://freecode.com/projects/sysstat aka. karagöz balığı

iostat komut çıktısına da bakmak istediğinizden emin olmak için, özellikle% iowait değerinin normal sistem yükü altında (% 1.0 veya daha düşük)% 5-10 altında olması gerekir.

STAT sütununda, bu işlemlerin kilitli ve IO için beklendiği anlamına gelen D durumlarını görüyorsanız ps çıkışına bakın, büyük olasılıkla denetleyici veya diskle ilgili bir donanım sorunu, SMART istatistiklerini ve ipucu için dmesg ve syslog'u kontrol edin

sar günlüğünü kontrol edin ve bu gerçekleşirse yoğun zamanları belirleyin ve bu süreyi disk yoğun cron işleri ile eşleştirmeye çalışın, örneğin ağ üzerinden yedekleme

disk performansınızı bonnie ++ ile karşılaştırabilirsiniz

Bu soru şimdi aylarca olmasına rağmen sıkıntıdan söz edeceğimi düşündüm. Benzer bir sorunu olan bu sayfayı bulan birisine yardımcı olabilir.

Deneyin.

strace "application"

ayrıca yapabilirsin

strace -e read,write "application"

sadece okuma / yazma olaylarını göstermek için.

Uygulama normal olarak yüklenir (başlatılması biraz daha yavaş olsa da) ve sorunu tetiklemek için normal olarak kullanabilirsiniz. Çıktı strace başlatmak için kullandığınız kabukta görünecektir.

Strace ile ilgili iyi bir şey, uygulamanın yavaşlamayı tetiklediği anda en son fonksiyon / çekirdek çağrısını görebilmenizdir. Sen eğer bulabilirsiniz /homehesapları NFS Hangi ardından uygulama dosya G / Ç üzerinde NFS için nedense ilişkin bazı sıkıntılar yaşıyor.