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

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

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

「sar -d」の出力、システムストールは午後12時58分から13時1分ごろに発生しました。

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

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

幸運にも次のピーク使用期間をキャッチできる場合は、iotopを使用して、プロセスごとのI / O統計をインタラクティブに調べることができます。

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]              

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

あなたは物事のカップルがあるかもしれませんが関与または排除するためにチェックすることができるように- /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をインストールしてください;-)

を使用し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

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

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