私はこの質問を見ました: ディスクへの重い書き込みを識別する方法?
そして、私は以前に dstat と atop を使用しました...しかし、それらはどのプロセスがディスクI/Oを引き起こしているのか正確に示していないようです。たとえば、dstatから:
dstat -ta --top-bio
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- ----most-expensive----
time |usr sys idl wai hiq siq| read writ| recv send| in out | int csw | block i/o process
14-12 16:16:25| 22 3 49 26 0 0|2324k 0 | 17k 6144B| 0 0 |1324 0 |
14-12 16:16:26| 24 3 30 43 0 0|4960k 8192B|1498B 4322B| 0 0 |1494 0 |wget 0 4096B
14-12 16:16:27| 25 4 38 33 0 0|4612k 548k|5011B 27k| 0 0 |1582 0 |kjournald 0 24k
14-12 16:16:28| 23 3 42 32 0 0|5072k 0 | 24k 4368B| 0 0 |1495 0 |
Dsk /合計が2〜5 MB /秒の高さに注目してください。しかし、「最も高価な」列を見てください。ここでは数バイト、そこに数KBあり、時には何もない場合もあります。 「atop」と同じです。全体的なディスク使用率は高いが、個々のプロセスの使用率は低い。 CentOS 5、カーネル2.6.18-53を実行しています。
新しいカーネルバージョンが必要ですか?多分どこかにいくつかのシステム構成設定? 'atop'ホームページでは、いくつかのカーネルパッチをインストールすることを推奨していますが、自分のカーネルを構成してコンパイルするという面倒な作業は避けたいと思います。
iotop( link )for starter;)私はあなたがその出力を投稿しているのを見ていません。
1:ロギングファイルシステムとatimeでほぼ同じ状況を経験しましたが、書き込みが増えました。
Noatimeを使用して再マウントし、ファイルシステムロギング(後でテストのみ)をオフにして、ファイルシステムベースかどうかを確認し、前述のように、プロセスベースの場合はiotopを確認します。
2:このパーティションは、再構築したばかりのRAIDアレイの一部ではないようですね。
3:非常に小さなファイルがたくさんあり(実際のブロックデバイスのブロックサイズやファイルシステムのブロックサイズよりもかなり小さい)、それらの小さなファイルを読み取っている場合、システムからブロック全体を読み取ってしまいます。それらのブロックのうち何も読み込まれません。
4:上記の方法で何も解決しない場合は、実行することでアクセスできるファイルのリストをいつでも取得できます
echo 1 > /proc/sys/vm/block_dump
システムのパフォーマンスが大幅に低下することに注意してください。手順は私の 前の投稿はこちら にあります