私は最近新しいサーバー（ddを使用）でいくつかのパフォーマンステストを行いましたが、なぜ読み取りパフォーマンスが書き込みパフォーマンスよりはるかに悪いのか疑問に思いました。他のアプローチが必要ですか？
両方のテストのファイルサイズは550 GB、読み取り：秒：3704 MB / s：148
書き込み: 秒単位: 1539 MB/秒単位: 357
書き込みコマンド：
time sh -c "dd if=/dev/zero of=/local/postgresql/bigfile
bs=8k count=67108864 && sync"
読み取りコマンド：
time dd if=/local/postgresql/bigfile of=/dev/null bs=8k
bash 時間コマンド出力:
real: 61m44.335s
user: 0m12.721s
sys: 10m35.884s
Bonnie++ 結果コマンド:
bonnie++ -f -D -n 0 -u root -d /local/postgresql/
その結果、ファイルサイズはRAMサイズの2倍になります。
書く:
419918K/秒
読む：
~ 187,000K/秒
答え1
実際にキャッシュではなくディスクに書き込んでいることを確認するには、書き込み同期フラグでパフォーマンスをテストする必要があります。conv=fdatasync書き込みが完了した後、バッファを強制的に同期させるために使用されます。バラよりここもっと学ぶ。
time dd .... conv=fdatasync
読み取りテストの場合、テスト前にキャッシュを削除します。
flush
echo 3 | sudo tee /proc/sys/vm/drop_caches
time dd ....
答え2
どのコマンドを使用しましたか？ddする非常にパフォーマンスに関する事項はオプションによって異なります。
しかし、あなたが書いた内容で判断すると、
私はあなたがおおよその要件に従ってディスクから読み取る小さな塊で読んでいると思います。
dd小さなチャンクを書くことができ、そのチャンクは記録されるのではなく、カーネルがそうする時間があると思うとディスクに書き込まれます。
これですでに違いが説明されます。そうですか？
答え3
私はこれから意味のあるベンチマークを得ることができるかどうか疑問に思いますdd。ddさまざまなデバイス間で実行される大規模シーケンシャル読み取りまたは大規模シーケンシャル非同期書き込みを示します。ワークロードが主にこれらのファイルシステム間の大容量ファイルのコピーで構成されている限り、問題ありません。しかし、それがあなたの仕事量だと思います。
最良の方法は、ディスク使用量を分析し、実際のI / Oベンチマークファミリ（リンクbonnie++など）を使用してさまざまな調整可能なパラメータ変更の効果をテストすることです。データベースの場合、ランダムな読み取りが大量に発生すると予想されます。定期的なバックアップを使用してマスターデータファイルの操作を設定してnoatime実行するdata=writebackことは、おそらくこれまでに保持している情報でできる最善の方法です。
大きな質問に答えるには、非同期書き込み（例：で行った操作dd）をメモリにバッファリングしてディスクにコミットすることができるためです。彼らタイプキューとバッファがいっぱいになる限り、スタックする前にディスクにコミットして再利用できるまで待つ必要があります。
一方、読み取りは定義に従ってI / Oバインドされているため、通常は同じ非同期操作を実行しません。read_ahead_kb近い将来のワークロード要件に合わせて、より多くの順次データをメモリにインポートするためにこのような作業を試すことができます。
それが今私が考えることができる答えです。ご質問がございましたらお知らせください。