Debugging I / O Linux latensi

Saya mengalami beberapa masalah I / O pada beberapa sistem Linux yang saya kelola. Mereka memanifestasikan dalam proses yang sering memblokir hingga beberapa detik dalam syscall sederhana seperti open (), unlink () atau close () pada file (yang merupakan masalah karena beberapa program yang terlibat memerlukan latensi I / O yang agak rendah untuk beroperasi tepat). Memang benar bahwa sistem yang bersangkutan mengalami beban I / O yang moderat, tetapi saya tidak bisa berpikir itu akan cukup untuk membenarkan waktu latensi yang sangat besar. Kadang-kadang, panggilan dapat selesai lebih dari 15 detik (meskipun lebih sering mereka membutuhkan 1 atau 2 atau 3 detik atau lebih).

Pertanyaan saya adalah: Bagaimana saya bisa mengetahui mengapa ini terjadi? Apa yang saya inginkan adalah beberapa alat yang dapat memberi tahu saya apa proses yang diblokir oleh kernel, dan mengapa apa yang mereka tidur sibuk, apa yang terjadi dengannya, dan hal-hal semacam itu. Apakah ada alat seperti itu, atau ada cara lain untuk mencoba men-debug apa yang terjadi?

Atau, tentu saja, jika Anda memiliki petunjuk mengenai apa sebenarnya yang terjadi, bagaimana hal itu dapat dihindari?

Sebagai catatan, sistem file yang saya gunakan adalah XFS.

Sekarang pada waktunya, saya telah berhasil menyelesaikan ini sendiri, jadi saya setidaknya bisa menindaklanjutinya sendiri untuk anak cucu.

Sayangnya, saya kehilangan masalah asli dalam peningkatan kernel, tetapi mendapatkan yang baru sebagai gantinya, bahkan lebih buruk dalam kinerja, dan sama sulit untuk dilacak. Teknik yang saya temukan adalah sebagai berikut:

Pertama-tama, blktrace/ blkparseadalah alat yang saya temukan cukup membantu. Ini memungkinkan penelusuran kemajuan permintaan I / O individu dengan banyak detail bermanfaat, seperti proses yang mengirimkan permintaan. Akan sangat membantu untuk tmpfsmengaktifkan output , sehingga penanganan penyimpanan jejak tidak mulai melacak sendiri.

Itu hanya membantu sejauh ini, jadi saya mengkompilasi kernel dengan lebih banyak fungsi debugging. Secara khusus, saya merasa ftracecukup membantu, karena memungkinkan saya untuk melacak proses yang berkinerja buruk di dalam ruang kernel, untuk melihat apa yang dilakukannya dan di mana ia diblokir. Mengkompilasi kernel debug juga memberikan WCHANhasil kerja ps, yang dapat bekerja sebagai cara yang lebih mudah untuk melihat apa yang sedang dilakukan proses di dalam kernel, setidaknya untuk kasus yang lebih sederhana.

Saya juga berharap agar LatencyTop bermanfaat, tetapi saya merasa cukup bermasalah, dan juga hanya menampilkan alasan latensi yang terlalu "tingkat tinggi" untuk benar-benar berguna, sayangnya.

Juga, saya merasa lebih bermanfaat daripada iostathanya melihat konten /sys/block/$DEVICE/statpada interval yang sangat dekat, seperti ini:

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

Lihat Documentation/iostats.txtdi pohon sumber kernel untuk format statfile. Melihatnya dalam jarak dekat memungkinkan saya untuk melihat waktu dan ukuran yang tepat dari ledakan I / O dan hal-hal semacam itu.

Pada akhirnya, saya menemukan bahwa masalah yang saya miliki setelah peningkatan kernel disebabkan oleh halaman yang stabil , sebuah fitur yang diperkenalkan di Linux 3.0, menyebabkan, dalam kasus saya, Berkeley DB berhenti untuk waktu yang lama ketika mengotori halaman dalam mmap'ednya file wilayah. Meskipun tampaknya mungkin untuk menambal fitur ini, dan juga bahwa masalah yang ditimbulkannya mungkin diperbaiki di Linux 3.9, saya telah memecahkan masalah terburuk yang saya miliki untuk saat ini dengan menambal Berkeley DB untuk memungkinkan saya meletakkan file wilayahnya di direktori yang berbeda (dalam kasus saya /dev/shm), memungkinkan saya untuk menghindari masalah sama sekali.

Menurut pengalaman saya alat statistik paling sederhana dan terinci yang dapat Anda instal untuk melacak masalah kinerja sistem misterius adalah http://freecode.com/projects/sysstat alias. sar

pasti Anda ingin melihat output perintah iostat juga, khususnya berapa% iowait Anda harus di bawah 5-10% di bawah beban sistem normal (di bawah 1,0 atau lebih).

lihat output ps jika di kolom STAT Anda melihat status D yang berarti proses tersebut dikunci dan menunggu IO, sangat mungkin masalah perangkat keras dengan controller atau disk, periksa statistik SMART serta dmesg dan syslog untuk petunjuk

periksa sar log dan identifikasi waktu puncak jika ini terjadi dan cobalah untuk mencocokkan waktu tersebut dengan pekerjaan cron intensif disk misalnya backup melalui jaringan

Anda dapat membandingkan kinerja disk Anda dengan Bonnie ++

Kupikir aku akan menyebutkan strace meskipun pertanyaan ini sudah berumur beberapa bulan. Mungkin membantu seseorang dengan masalah serupa yang menemukan halaman ini.

mencoba.

strace "application"

Anda juga bisa melakukannya

strace -e read,write "application"

hanya menampilkan acara baca / tulis.

Aplikasi akan memuat seperti biasa (meskipun sedikit lebih lambat untuk diluncurkan) dan Anda dapat menggunakannya seperti biasa untuk memicu masalah. Output akan muncul di shell yang Anda gunakan untuk meluncurkan strace.

Hal yang baik tentang strace adalah Anda dapat melihat fungsi / panggilan kernel terbaru pada saat aplikasi memicu perlambatan. Anda mungkin menemukan bahwa jika /homeakun Anda berada di NFS maka aplikasi mengalami kesulitan dengan file I / O lebih dari NFS karena beberapa alasan.