仮想プロセスのIO使用量を測定する場合、htop出力は明確ではありません。

仮想プロセスのIO使用量を測定する場合、htop出力は明確ではありません。

test.sh私は以下を行う簡単なスクリプトを書いています。while true; do cp ./target-file ./target-file.tmp; doneここではtarget-filecreateを使用して出力がdd if=/dev/urandom of=target-file bs=1M count=100あります。du -h target-file101M target-file

プロセスのディスクIOを測定するためにhtopを使ってみました。すべての列を有効にしました(htopで利用可能:F2- >「列」を選択 - >右下にスクロール)。

高い柱

以下は、特定時点の出力例です(下の行を参照)。

htopは実行中のプロセスをキャプチャします。

私はいくつかのパラメータを知っています:RD_CHARより大きいWR_CHARRD_SYSCより大きいWR_SYSC。論理的に機能するには、cpまずファイルを読み、次にファイルに書き込む必要があります。だからそれは意味があります。

しかしはDISK_READ一貫0.00 B/sして。明らかに、これがプロセスが毎秒バイトを読み取らないことを意味すると仮定するのは間違っています。あるいは、読むよりも多くの情報を書いていると仮定するのも正しくありません。IO_RBYTESIO_WBYTES

質問IO_RBYTES:報告された非常に低い合計値を論理的に理解する方法はDISK_READ

ベストアンサー1

/proc/$pid/io次のフィールドの履歴を見つけることができます。https://man7.org/linux/man-pages/man5/proc.5.html

rchar: 読み取った文字数 この
操作のためにリポジトリから読み取ったバイト数。これは、プロセスがread(2)と同様のシステムコールに渡したバイトの合計です。これにはターミナルI / Oなどが含まれ、物理物理ディスクI / Oが必要かどうかに影響されません(読み取りはページキャッシュですでに満たされている可能性があります)。

wchar:書き込まれた文字数この
操作のためにディスクに書き込まれたか書き込まれたバイト数。 rcharに似た警告がここに適用されます。

read_bytes:バイト読み取りは、
このプロセスが実際にストレージ階層から取得したバイト数を計算しようとします。これは、ブロックサポートファイルシステムの場合は正確です。

write_bytes: 書き込んだバイト数 この
プロセスの結果、ストレージ階層に転送されたバイト数を計算しようとします。

これらの定義にはいくつかの重要な微妙さがあります。

 

私はいくつかのパラメータを知っています。 RD_CHAR は WR_CHAR より大きく、RD_SYSC は WR_SYSC より大きい。論理的にcpが機能するには、まずファイルを読み、次にファイルに書き込む必要があります。だからそれは意味があります。

はい、そうです。しかし、もっとたくさんあります。rcharメトリックには、wcharSTDIN、STDOUT、STDERR、ネットワークなどを含むすべての読み書きが含まれます。これでandを
使用していますが、これはあまり多くの出力を提供しないため、この特定のシナリオでは大きな意味を持たないはずです。違い。ただし、これはより複雑なプロセスを扱うときに注意する必要があります。cpdd

 

ただし、DISK_READは常に0.00B / sで、IO_RBYTESはIO_WBYTESよりはるかに小さいです。明らかに、これがプロセスが毎秒バイトを読み取らないことを意味すると仮定するのは間違っています。

この動作を理解するための鍵は次のとおりです。

read_bytes:バイト読み取りは、
このプロセスが実際にストレージ階層から取得したバイト数を計算しようとします。

あなたの場合、入力データはまだページキャッシュにあるので、実際にディスクにアクセスするのではなく、メモリから読み取ることです。ただし、新しいファイルに書き込んでいるため、出力はディスクに書き込まれます。

 

Tl;Dr: *文字表示には以下が含まれます。プロセス内のすべてのI/O、ディスク、TTY、ネットワークなどが含まれます。 *バイト指標のみ物理ディスクI/O

おすすめ記事