Context:過去2分間のトップ履歴からサービスのI/O使用量を計算するスクリプトを作成しています(トップのサンプリングは1分ごとに構成されています)。次のコマンドを使用して履歴ファイルを生成しています。
atop -P DSK,PRD -b [time] -e [time] -r > somefile_to_read_from
atop
の解析可能な出力オプション(-P
)およびラベルDSK
およびPRD
。
atop
のマニュアルページから、DSK
について次のように書かれています。
すべての論理ボリューム/複数のデバイス/ハードディスクに対して、1行が表示されます。後続のフィールド:名前、I/Oに費やされたミリ秒数、発行された読み取りの数、読み取りのために転送されたセクターの数、発行された書き込みの数、および転送されたセクターの数書き込み用。
PRD
の場合、次のようになります。
すべてのプロセスについて、1行が表示されます。後続のフィールド:PID、名前(括弧内)、状態、インストールされた廃止されたカーネルパッチ(「n」)、使用された標準io統計(「y」または「n」)、ディスク上の読み取り数、読み取られたセクターの累積数、ディスクへの書き込み数、書き込まれたセクターの累積数、書き込まれたセクターのキャンセル数、TGID(関連するタスク/スレッドのグループ番号)およびis_process(y/n)。
同じものだと思いました。ただし、ほとんどの場合、I/O使用量が100%をはるかに超える値を取得します(たとえば、Apacheでab
を実行している場合)。プログラミングロジックとアルゴリズムに起因する問題だと思いましたが、何時間も壁に頭をぶつけて、自分が犯したかもしれない間違いを思いつかず、さまざまな方法で計算してみました。 、それでも同じ結果が得られます。
そこで、フィルタリングした後、生成した履歴ファイルを開いて読み始め、そのようなI/O使用量があることを監視したプロセスのみを表示しました(この場合は、ベンチマークを実行したため、Apache)。そして、DSK
の-発行された書き込みの数がApacheのすべてのPRD
行の合計よりもはるかに少ないという事実に気づきました 'ディスクへの書き込み数。
何か間違ったことを理解したのか、何が間違っているのかわかりません。履歴ファイルは大きすぎて表示できませんが、必要に応じてPastebinなどにアップロードできます。
私の質問は、DSK
の-発行された書き込み/読み取りの数は何を指しているのか、それはPRD
の-読み取り/書き込みの数)と同じではないかということです。ディスク上?そうでない場合、topの履歴を使用して単一プロセスのI/O使用量を計算する方法は何でしょうか?
まず第一に私のman atop
は言う:
カウンタ「ディスクの読み取り数」と「ディスクの書き込み数」は、いずれにせよ廃止されています。
バージョンの上部:2.3.0-2017/03/25 09:59:59
man iostat
から:
転送は、デバイスへのI/O要求です。複数の論理要求を組み合わせて、デバイスへのI/O要求にすることができます。
これが、プロセスI/Oの合計がDSK
の値を超える理由を説明していると思います。
したがって、単一プロセスの適切に正確なI/O使用量は、process_io / sum_of_all_process_io
になります。論理的な要求がどの程度正確に組み合わされているかを判断する方法(私が知っている)がないため、100%正確ではありません。
結果は正しく、効率的なディスクIOの結果だと思います。 write-back(stackoverflow) システムでは、発行される書き込みの数はディスクへの実際の書き込みよりも少なくなければなりませんが、ライトスルーシステムでは、発行される書き込みの量の合計は等しくなければなりません。 write-combining(wikipedia) がないため、ディスクへの書き込み数に。
から Webopedia :
ライトバックキャッシングは、メインメモリへの書き込み操作の数を減らすため、ライトスルーキャッシングよりもパフォーマンスがいくらか向上します。このパフォーマンスの向上により、システムがクラッシュした場合にデータが失われる可能性があるというわずかなリスクが発生します。
このため、topのDSKラベルは、ライトバックシステムで発生する実際のディスクIOのより代表的な値です。
プロセスごとのioの場合 このserverfaultの質問 が役立つ場合があります。
このHuaweiフォーラムスレッドには、ライトスルーとライトバックの優れた説明があります それが出力に影響を与えていると仮定します。
私は絶対に間違っている可能性がありますが、ファイルシステムIOバッファリング、ドライブセクターサイズおよびIOのサイズの事実に関連している可能性があります。たとえば、ディスクブロックサイズが512の場合バイトとアプリケーションが1024バイトを書き込んでいる場合、1つのアプリケーションIOはドライブの2IOに相当します。アプリケーションとドライブの間に少なくともファイルシステムとボリュームマネージャーがあり、両方があると想像してください。それらの中には、独自のブロックサイズがある場合があります。