しばらく見ていて期待通りになっていないのですが、何かがおかしいのか、期待が間違っているのかわかりません。
つまり、100GBを超えるRAMを搭載したシステムがあり、dirty_background_bytes
を9663676416(9GB)に設定し、dirty_bytes
をその2倍(19327352832または18GB)に設定しました。
私の考えでは、これにより最大9GBをファイルに書き込むことができますが、実際にはメモリ内にあるだけで、ディスクにアクセスする必要はありません。私のdirty_expire_centisecs
はデフォルトの3000
(30秒)です。
だから私が走るとき:
# dd if=/dev/zero of=/data/disk_test bs=1M count=2000
そして走った:
# while sleep 5; do egrep 'Dirty|Writeback' /proc/meminfo | awk '{print $2;}' | xargs; done
(ダーティバイトをkbで、Writebackをkbで、WritebackTmpをkbで5秒のスナップショットで出力)
2GBをページキャッシュにダンプし、そこに30秒間置いてから、データをディスクに書き始めると予想していました(9GBのバックグラウンド比を超えることはなかったため)。
代わりに私が見たのは:
3716 0 0
4948 0 0
3536 0 0
1801912 18492 0
558664 31860 0
7244 0 0
8404 0 0
ページキャッシュがジャンプするとすぐに、開始した場所に戻るまで、すでにデータが書き出されていました。
私が実際に取り組んでいるのは、基本的に、プロセスのボトルネックがディスクIOまたはその他の要因であるかどうかを確認しようとしていることですが、途中でこの動作に混乱しました。プロセスはまだバッファゾーンで実行されています。ディスクの書き込みパフォーマンスは、メモリにダンプするだけなので、実際には関係ありません。
それで、私はこれらの機能が機能することになっている方法を誤解していますか、それとも何か奇妙なことが起こっていますか?
これは、dd
コマンドのリンクを解除し、反復ごとに新しいdisk_testを作成することの副作用である可能性があります。
最初に単一のdd if=/dev/zero of=/data/disk_test bs=1M count=2000
コマンドでターゲットファイルを作成してから、dd if=/dev/zero of=/data/disk_test bs=1M count=2000 conv=notrunc,nocreat
コマンドでループを実行してみてください。
説明:notrunc
過去に、アプリケーションがreplace-via-renameとreplace-viaを実行しないようにするためにヒューリスティックが追加されたため、違いが生じます。 -データを破損するために、直後に切り捨ててクラッシュします。このヒューリスティックは基本的に、open-> written-> truncatedファイルに属するデータを強制的にフラッシュします。
から マウントマニュアルページ :
auto_da_alloc | noauto_da_alloc
Noauto_da_allocが次のようなパターンを介して既存のファイルを置き換える場合、多くの壊れたアプリケーションはfsync()を使用しません
fd = open( "foo.new")/ write(fd、..)/ close(fd)/ rename( "foo.new"、 "foo")
またはさらに悪い
fd = open( "foo"、O_TRUNC)/ write(fd、..)/ close(fd)。
Auto_da_allocが有効になっている場合、ext4はreplace-via-renameおよびreplace-via-truncateパターンを検出し、次のジャーナルコミット時に、デフォルトのdata = orderedモードで、のデータブロックが割り当てられるように遅延割り当てブロックを強制的に割り当てます。新しいファイルは、rename()操作がコミットされる前に強制的にディスクに入れられます。これにより、ext3とほぼ同じレベルの保証が提供され、遅延割り当てブロックがディスクに強制される前にシステムがクラッシュしたときに発生する可能性がある「長さがゼロ」の問題が回避されます。
XFS FAQ でも戦利品を与える