web-dev-qa-db-ja.com

プロセスごとのディスクI / O使用率を確認する方法

Linuxシステムの停止に問題があり、sysstat/sarがシステム停止時のディスクI/O使用率、平均サービス時間、平均待機時間の巨大なピークを報告することがわかりました。

次回、これらのピークを引き起こしているプロセスを特定するにはどうすればよいですか?
sarを使用することは可能ですか(つまり、すでに記録されているsarファイルからこの情報を見つけることができますか?

「sar -d」の出力で、システムストールが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

これは私が昨日始めたスレッドへのフォローアップの質問です: 負荷とディスクブロック待機の突然のピーク 、私は新しいトピックを作成したことでいいと思います/私はまだ問題を解決できていないので、問題について質問します。

48
Avada Kedavra

運が良ければ、次のピーク使用期間を把握できれば、プロセスごとのI/O統計を iotop を使用してインタラクティブに調べることができます。

50
halp

次のコマンドでpidstatを使用して、20秒ごとにプロセスごとの累積io統計を出力できます。

# pidstat -dl 20

各行には次の列があります。

  • PID-プロセスID
  • kB_rd/s-タスクがディスクから1秒あたりに読み取らせたキロバイト数。
  • kB_wr/s-タスクが引き起こしたキロバイト数、または1秒あたりにディスクに書き込まれるキロバイト数。
  • kB_ccwr/s-タスクによるディスクへの書き込みがキャンセルされたキロバイト数。これは、タスクがダーティページキャッシュを切り捨てたときに発生する可能性があります。この場合、一部のIO別のタスクが考慮されている)は発生しません。
  • コマンド-タスクのコマンド名。

出力は次のようになります。

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]              
31
user920391

進行中の監視に勝るものはありません。イベント後に時間依存のデータを取り戻すことはできません...

ただし、次の2つがあります可能性があります関係があるか、または排除するためにチェックできる— /proc あなたの友だちです。

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

フィールド10、11は、書き込まれたセクターの累積と、書き込みの累積時間(ms)です。これにより、ホットファイルシステムパーティションが表示されます。

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

それらのフィールドは、PID、コマンド、および累積IO待機ティックです。 まだ実行中の場合のみですが、これによりホットプロセスが表示されます。 (おそらく、ファイルシステムのジャーナリングスレッドは無視する必要があります。)

上記の有用性は、稼働時間、長時間実行されているプロセスの性質、およびファイルシステムの使用方法によって異なります。

警告:2.6より前のカーネルには適用されません。不明な場合はドキュメントを確認してください。

(さあ、あなたの未来-自分のために、Munin/Nagios/Cacti/whateverをインストールしてください;-)

12
mr.spuratic

atopを使用します。 ( http://www.atoptool.nl/

atopが対話形式で後で読み取ることができる圧縮ファイルにデータを書き込みます。 10秒ごとに読み取り(デルタ)します。 1080回実行します(3時間。これを忘れると、出力ファイルによってディスクが不足することはありません)。

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

悪いことが再び起こった後:

(まだバックグラウンドで実行されている場合でも、10秒ごとに追加されます)

% atop -r historical_everything.atop

あなたがIOを言ったので、私は3つのキーを押すでしょう: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
11
Wayne Walker

btraceを使用します。使いやすいです。たとえばbtrace /dev/sda。コマンドが利用できない場合、おそらくパッケージblktraceで利用できます。

[〜#〜] edit [〜#〜]:カーネルでdebugfsが有効になっていないため、date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf または類似。もちろん、ページフォールトのロギングは、btraceを使用することとまったく同じではありませんが、運が良ければ、ほとんどのディスクを消費しているプロセスに関するヒントを提供できます。 I/O集中型のサーバーの1つを試してみて、I/Oを大量に消費していることがわかっているプロセスをリストに含めました。

5