linux cpコマンドがディスクIOを消費しないのはなぜですか？

cp最初の操作中にデータがディスクにフラッシュされていないが、2番目の操作中にディスクにフラッシュされた可能性があります。

vm.dirty_background_bytesこの場合に該当するかどうかを確認するには、1048576（1MiB）などの小さい値に設定してみてください。sysctl -w vm.dirty_background_bytes=1048576これにより、最初のcpシーンにI / Oが表示されるはずです。

ここで何が起こっているのでしょうか？

同期および/または直接I / Oの場合を除いて、ディスクへの書き込みはしきい値に達するまでメモリにバッファリングされ、しきい値に達するとバックグラウンドでディスクへのフラッシュが開始されます。このしきい値には正式な名前はありませんが、によって制御されるvm.dirty_background_bytesため、vm.dirty_background_ratio「ダーティーバックグラウンドしきい値」と呼びます。カーネル文書から:

vm.dirty_background_bytes

バックグラウンドカーネルフラッシュスレッドが書き込みを開始するダーティメモリの量を含みます。

メモ: dirty_background_bytesうん相手dirty_background_ratio。一度に 1 つしか指定できません。 1 つの sysctl が作成されると、評価のためにダーティメモリ制限が直ちに考慮されますが、もう一方の sysctl は読み出し時に 0 を表示します。

dirty_background_ratio

バックグラウンドカーネルリフレッシュスレッドがダーティデータの書き込みを開始するページ数を含みます（使用可能ページと回収可能ページを含む合計空きメモリの割合）。

使用可能な合計メモリーは、合計システム・メモリーと同じではありません。

vm.dirty_bytesそしてvm.dirty_ratio

このしきい値に加えて、2番目のしきい値があります。まあ、これは限界ではなくしきい値ではなく、vm.dirty_bytesによって制御されますvm.dirty_ratio。繰り返しますが、正式な名称がないので「ダーティーリミット」と呼びます。十分なデータが「記録」されているが基本ブロックデバイスにコミットされていない場合、追加の試みは書き込みwriteI / Oが完了するのを待つ必要があります。 （私は彼らが待たなければならないデータの正確な詳細を知りません。おそらくI / Oスケジューラの機能でしょう。わかりません。）

なぜ？

ディスク速度が非常に遅い。回転する錆の場合は特にそうです。したがって、ディスクの読み取り/書き込みヘッドが読み取り要求を満たすために移動すると、読み取り要求が完了し、書き込み要求が開始されるまで書き込み要求を処理できません。 (逆)

効率

そのため、書き込み要求をメモリにバッファリングし、読み取ったデータをキャッシュします。ジョブを遅いディスクからより高速なメモリに移動します。最後に、データをディスクにコミットすると、作業するデータ量が増え、ナビゲーション時間を最小限に抑えるようにデータを書き込むことができます。 （SSDを使用している場合は、ディスクナビゲーション時間の概念をSSDブロックの再フラッシュに置き換えます。再フラッシュは、SSDの寿命を短縮し、SSDが自己書き込みで非表示にしようとする遅い作業です（成功の程度はさまざまです）。）。

vm.dirty_background_bytesカーネルがディスクにデータを書き込もうとする前に、カーネルがバッファリングするデータ量を使用して調整できますvm.dirty_background_ratio。

バッファリングされた書き込みデータが多すぎます。

書き込むデータの量がディスクに到達できる速度に比べて大きすぎると、最終的にはシステムメモリがすべて使用されます。まず、読み取りキャッシュが消えます。つまり、メモリからの読み取り要求を減らし、ディスクから提供する必要があるため、書き込み速度がさらに遅くなります。書き込み圧力がまだ緩和されていない場合、最終的にメモリ割り当ては書き込みキャッシュが一部を解放するのを待つ必要があり、これははるかに混乱します。

だから私たちは「ちょっと待ってください。データが悪くなる前にディスクにデータを書き込む時間です」と言うことができますvm.dirty_bytes。vm.dirty_ratio

まだデータが多すぎます。

しかし、I/O のハードストップは非常に支障をきたします。ディスクの読み取りプロセスがすでに非常に遅いため、数秒から数秒かかることがあります。分このデータを更新するには、vm.dirty_bytesデフォルト値20を考慮してください。システムに16GiB RAMがあり、スワップ領域がない場合、3.4GiBのデータがディスクにフラッシュされるのを待っている間にI / Oがブロックされる可能性があります。 128GiB RAMを搭載したサーバーで使用しますか？ 27.5GiBのデータを待っている間サービスタイムアウト！

vm.dirty_bytesしたがって、（またはvm.dirty_ratio必要に応じて）かなり低く保つのが役立ちます。勝つこの厳しいしきい値は、サービスに最小限のダメージを与えます。

良い価値とは何ですか？

これらの調整可能なパラメータを使用すると、常にスループットとレイテンシの間でバランスが取れます。バッファリングが多すぎるとスループットは高くなりますが、待ち時間はひどいです。バッファが小さすぎるとスループットが低下しますが、待ち時間が長くなります。

単一のディスクを備えたワークステーションとラップトップでは、vm.dirty_background_bytes約1MiB、vm.dirty_bytes8MiBから16MiBの間の設定を好みます。シングルユーザーシステムが16MiB以上のスループットを達成することはほとんど見られませんが、Webブラウザのデータストレージなどの同期ワークロードでは、遅延が非常に長くなる可能性があります。

ストライプパリティ配列を持つすべての項目で、配列ストライプ幅の倍数が良い開始値であることがわかりました。vm.dirty_background_bytesこれにより、パリティの可能性を更新するときに読み取り/更新/書き込みシーケンスを実行する必要性が減り、配列のスループットが向上します。

の場合、vm.dirty_bytesサービスが受ける可能性のある遅延時間によって異なります。私自身は、ブロックデバイスの理論的スループットを計算し、それを使用して約100ミリ秒以内にどれだけのデータが移動できるかを把握し、vm.dirty_bytesそれに応じて設定するのが好きです。 100msの待ち時間は膨大ですが（私の環境では）致命的ではありません。

ただし、これはすべて環境によって異なり、これはあなたに最適なものを見つけるための始点です。