Sekarang pada waktunya, saya telah berhasil menyelesaikannya sendiri, jadi setidaknya saya dapat menindaklanjutinya sendiri untuk anak cucu.
Sayangnya, saya kehilangan masalah aslinya dalam pemutakhiran kernel, tetapi malah mendapatkan yang baru, bahkan kinerjanya lebih buruk, dan sama sulitnya untuk dilacak. Teknik yang saya temukan adalah sebagai berikut:
Pertama-tama, blktrace /blkparse adalah alat yang menurut saya cukup membantu. Ini memungkinkan pelacakan progres permintaan I/O individual dengan banyak detail bermanfaat, seperti proses yang mengirimkan permintaan. Sangat membantu untuk menempatkan output pada tmpfs , agar penanganan penyimpanan pelacakan tidak mulai melacak dirinya sendiri.
Itu hanya membantu sejauh ini, jadi saya mengkompilasi kernel dengan lebih banyak fungsi debug. Secara khusus, saya menemukan ftrace cukup membantu, karena memungkinkan saya untuk melacak proses yang berkinerja buruk di dalam ruang kernel, untuk melihat apa yang dilakukannya dan di mana ia diblokir. Mengompilasi kernel debug juga menyediakan WCHAN yang berfungsi keluaran untuk ps juga, yang dapat berfungsi sebagai cara yang lebih mudah untuk melihat apa yang dilakukan suatu proses di dalam kernel, setidaknya untuk kasus yang lebih sederhana.
Saya juga berharap LatencyTop berguna, tetapi menurut saya itu cukup bermasalah, dan sayangnya, itu hanya menampilkan alasan latensi yang terlalu "tingkat tinggi" untuk benar-benar berguna.
Selain itu, menurut saya ini lebih bermanfaat daripada iostat untuk sekadar melihat konten /sys/block/$DEVICE/stat pada interval yang sangat dekat, seperti ini:
while :; do cat /sys/block/sda/stat; sleep .1; done
Lihat Documentation/iostats.txt di pohon sumber kernel untuk format stat mengajukan. Melihatnya dalam jarak dekat memungkinkan saya melihat waktu dan ukuran yang tepat dari semburan I/O dan hal-hal semacamnya.
Pada akhirnya, saya menemukan bahwa masalah yang saya alami setelah pemutakhiran kernel disebabkan oleh halaman stabil, sebuah fitur yang diperkenalkan di Linux 3.0, menyebabkan, dalam kasus saya, Berkeley DB berhenti untuk waktu yang lama saat mengotori halaman di mmap'ed-nya file wilayah. Meskipun tampaknya mungkin untuk menambal fitur ini, dan juga bahwa masalah yang ditimbulkannya dapat diperbaiki di Linux 3.9, saya telah memecahkan masalah terburuk yang saya miliki untuk saat ini dengan menambal Berkeley DB agar saya dapat meletakkan file wilayahnya di direktori yang berbeda (dalam kasus saya /dev/shm ), memungkinkan saya menghindari masalah sama sekali.
Menurut pengalaman saya, alat statistik paling sederhana dan terperinci yang dapat Anda instal untuk melacak masalah kinerja sistem yang 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 terkunci dan menunggu IO, kemungkinan besar masalah perangkat keras dengan pengontrol atau disk, periksa statistik S.M.A.R.T serta dmesg dan syslog untuk petunjuk
periksa log sar dan identifikasi waktu puncak jika ini pernah terjadi dan coba cocokkan waktu tersebut dengan pekerjaan cron intensif disk misalnya pencadangan melalui jaringan
Anda dapat mengukur kinerja disk Anda dengan bonnie++
Saya pikir saya akan menyebutkan strace meskipun pertanyaan ini sekarang sudah berumur beberapa bulan. Ini dapat membantu seseorang dengan masalah serupa yang menemukan halaman ini.
coba.
strace "application"
Anda juga bisa melakukannya
strace -e read,write "application"
untuk hanya menampilkan acara baca/tulis.
Aplikasi akan memuat seperti biasa (walaupun sedikit lebih lambat untuk diluncurkan) dan Anda dapat menggunakannya seperti biasa untuk memicu masalah. Keluaran akan muncul di shell yang Anda gunakan untuk meluncurkan strace.
Hal yang baik tentang strace adalah Anda dapat melihat panggilan fungsi/kernel terbaru pada saat aplikasi memicu pelambatan. Anda mungkin menemukan bahwa jika /home Anda akun berada di NFS maka aplikasi mengalami kesulitan dengan file I/O melalui NFS karena beberapa alasan.