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
これは私が昨日始めたスレッドへのフォローアップの質問です: 負荷とディスクブロック待機の突然のピーク 、私は新しいトピックを作成したことでいいと思います/私はまだ問題を解決できていないので、問題について質問します。
運が良ければ、次のピーク使用期間を把握できれば、プロセスごとのI/O統計を iotop を使用してインタラクティブに調べることができます。
次のコマンドでpidstatを使用して、20秒ごとにプロセスごとの累積io統計を出力できます。
# pidstat -dl 20
各行には次の列があります。
出力は次のようになります。
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]
進行中の監視に勝るものはありません。イベント後に時間依存のデータを取り戻すことはできません...
ただし、次の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をインストールしてください;-)
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で利用できます。
[〜#〜] edit [〜#〜]:カーネルでdebugfsが有効になっていないため、date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf
または類似。もちろん、ページフォールトのロギングは、btraceを使用することとまったく同じではありませんが、運が良ければ、ほとんどのディスクを消費しているプロセスに関するヒントを提供できます。 I/O集中型のサーバーの1つを試してみて、I/Oを大量に消費していることがわかっているプロセスをリストに含めました。