Bagaimana cara memeriksa penggunaan I / O disk per proses

45

Saya mempunyai masalah dengan sistem Linux yang macet dan saya telah menemukan sysstat / sar untuk melaporkan puncak besar dalam pemanfaatan I / O disk, waktu layanan rata-rata serta waktu tunggu rata-rata pada saat sistem berhenti.

Bagaimana saya bisa menentukan proses mana yang menyebabkan puncak ini saat berikutnya terjadi?
Apakah mungkin dilakukan dengan sar (yaitu: dapatkah saya menemukan info ini dari file sar yang direkam sebelumnya?

Output untuk "sar -d", system stall terjadi sekitar 12.58-13.01pm.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

Ini adalah pertanyaan lanjutan untuk utas yang saya mulai kemarin: Puncak tiba-tiba di blok menunggu dan disk menunggu , saya harap tidak apa-apa bahwa saya membuat topik / pertanyaan baru tentang masalah ini karena saya belum dapat menyelesaikan masalah.

Avada Kedavra
sumber
Kedengarannya seperti masalahnya mungkin kurang proses tertentu dan lebih merupakan disk sporadis tidak responsif. Disk melakukan hal-hal semacam ini yang pada level sistem nampak seperti tebing yang dihantam sistem. Jika Anda tidak menemukan penyebabnya, maka inilah saatnya untuk menyelidiki sub-sistem disk.
slashdot
unix.stackexchange.com/questions/21295/… || stackoverflow.com/questions/14021810/…
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件
Menggunakan htop serverfault.com/a/25034/373867
qwr

Jawaban:

47

Jika Anda cukup beruntung untuk menangkap periode pemanfaatan puncak berikutnya, Anda dapat mempelajari statistik I / O per-proses secara interaktif, menggunakan iotop .

halp
sumber
Hei terima kasih! Namun mainan aneh lain untuk disimpan di kotak alat saya. :-)
Janne Pikkarainen
Menjalankan iotop dalam mode batch bisa menjadi pelengkap / pengganti yang sangat baik untuk solusi "ps -eo" di atas. Terima kasih!
Avada Kedavra
2
Luar biasa, "iotop -n 1 -b -o" memberikan output yang saya butuhkan. Terima kasih!
Avada Kedavra
sepertinya ini membutuhkan akses root ke sistem untuk menjalankan
user5359531
30

Anda dapat menggunakan pidstat untuk mencetak statistik io kumulatif per proses setiap 20 detik dengan perintah ini:

# pidstat -dl 20

Setiap baris akan memiliki kolom berikut:

  • PID - ID proses
  • kB_rd / s - Jumlah kilobyte yang menyebabkan tugas dibaca dari disk per detik.
  • kB_wr / s - Jumlah kilobyte yang disebabkan oleh tugas, atau harus ditulis ke disk per detik.
  • kB_ccwr / s - Jumlah kilobyte yang penulisan ke disk telah dibatalkan oleh tugas. Ini dapat terjadi ketika tugas memotong beberapa pagecache kotor. Dalam hal ini, beberapa IO yang tugasnya telah dipertanggungjawabkan tidak akan terjadi.
  • Command - Nama perintah tugas.

Output terlihat seperti ini:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              
pengguna920391
sumber
10

Tidak ada yang mengalahkan pemantauan yang sedang berlangsung, Anda tidak bisa mendapatkan kembali data sensitif waktu setelah acara ...

Ada beberapa hal yang mungkin bisa Anda periksa untuk mengimplikasikan atau menghilangkannya - /procadalah teman Anda.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Bidang 10, 11 adalah akumulasi sektor tertulis, dan akumulasi waktu (ms) penulisan. Ini akan menunjukkan partisi sistem file panas Anda.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

Bidang-bidang tersebut adalah PID, perintah dan kutu tunggu-tunggu IO kumulatif. Ini akan menunjukkan proses panas Anda, meskipun hanya jika masih berjalan . (Anda mungkin ingin mengabaikan utas penjurnalan filesystem Anda.)

Kegunaan di atas tergantung pada uptime, sifat dari proses Anda yang sudah berjalan lama, dan bagaimana sistem file Anda digunakan.

Peringatan: tidak berlaku untuk kernel pra-2.6, periksa dokumentasi Anda jika tidak yakin.

(Sekarang pergi dan bantulah masa depan Anda sendiri, pasang Munin / Nagios / Cacti / apa pun ;-)

mr.spuratic
sumber
10

Gunakan atop. ( http://www.atoptool.nl/ )

Tulis data ke file terkompresi yang atopdapat dibaca nanti dengan gaya interaktif. Ambil pembacaan (delta) setiap 10 detik. lakukan 1080 kali (3 jam; jadi jika Anda melupakannya file output tidak akan kehabisan disk):

$ atop -a -w historical_everything.atop 10 1080 &

Setelah hal buruk terjadi lagi:

(bahkan jika masih berjalan di latar belakang, itu hanya ditambahkan setiap 10 detik)

% atop -r historical_everything.atop

Karena Anda mengatakan IO, saya akan menekan 3 tombol: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display
Wayne Walker
sumber
5

Gunakan btrace. Mudah digunakan, misalnya btrace /dev/sda. Jika perintah tidak tersedia, itu mungkin tersedia dalam paket blktrace .

EDIT : Karena debugf tidak diaktifkan di kernel, Anda mungkin mencoba date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfatau serupa. Kesalahan halaman loging tentu saja tidak sama dengan menggunakan btrace, tetapi jika Anda beruntung, itu MUNGKIN memberi Anda beberapa petunjuk tentang proses lapar disk paling banyak. Saya baru saja mencoba salah satu dari server saya yang paling intensif I / O dan daftar termasuk proses yang saya tahu mengkonsumsi banyak I / O.

Janne Pikkarainen
sumber
Halo Janne, sayangnya kernel tidak dikompilasi dengan sistem file debug, dan ini adalah sistem live jadi saya tidak dapat mengkompilasi ulang kernel. Apakah ada cara lain untuk melakukan ini tanpa kompilasi ulang?
Avada Kedavra
OK, saya sedikit mengedit balasan saya :)
Janne Pikkarainen
Hebat, sekarang kita pergi ke suatu tempat! Saya berpikir tentang memasukkan ini ke dalam cronjob dan melaksanakannya bersamaan dengan pekerjaan sar cron. Kemudian, lain kali server berhenti saya harus bisa membandingkan tingkat kesalahan halaman untuk melihat proses / proses mana yang memiliki tingkat peningkatan kesalahan halaman. Saya kira saya bisa sial dan melihat kenaikan di disk io untuk semua proses selama warung, tapi itu pasti patut dicoba. Janne terima kasih! (saya akan memilih jawaban Anda jika saya bisa: S)
Avada Kedavra
Sama-sama. Biarkan saya tahu bagaimana kelanjutannya, ini hanya upaya pemecahan masalah yang kreatif dari saya. :-)
Janne Pikkarainen
Output iotop lebih mudah diinterpretasikan, jadi saya tidak bisa menerima solusi itu. Saya akan kembali untuk memberikan suara pada jawaban Anda segera setelah saya mendapatkan cukup tenaga untuk melakukannya. Terima kasih atas dukunganmu!
Avada Kedavra