読み取り/書き込みブロックサイズパフォーマンス結果は一貫していません。テストは正しいですか?

読み取り/書き込みブロックサイズパフォーマンス結果は一貫していません。テストは正しいですか?

IO不良のためにグリッド操作で発生する可能性があるボトルネックを識別するために、ファイルシステムのブロックサイズに基づいていくつかのテストを実行しようとしています。作業中に8096Bの小さなファイル増加がたくさんあり、FSブロックサイズは次のとおりです。

stat -fc %s /my/filesytem
1048576

これは最適ではありません。この動作をシミュレートするために、1GBから20GBの2つの小さなランダムファイルを作成し、ソースddとして /dev/urandom次のPythonコードを試しました。

#!/bin/python
bsize=8096
print('File random.20g1')
print(strftime("%Y-%m-%d_%H:%M:%S"))
f1= open('random.20g1','rb')
f2= open('random.20g1.dest','wb')

while True:
   b = f1.read(bsize)
   if b:
       f2.write(b)
   else:
       break
print(strftime("%Y-%m-%d_%H:%M:%S"))

私も同じことを試しましたbsize=1048576

私は最初に8096と1048576のブロックサイズの間に4秒という小さな読み書き時間の違いを観察しました(ブロックサイズは読み/書き込み時間が4秒短かった)。
最初の結果は有望でしたが、ファイルサイズを20 GBに増やしたり、10 GBのファイルで同じことをするなどの追加テストでは、パフォーマンスには常に同じ4/3秒の違いがあり、ゲインは決してありませんでした。同様にファイルのサイズが変更されます。

テスト中に私が何か間違っているのでしょうか?それともこれでいいと思いますか?
たとえば、ファイルサイズの増加に対する改善点を確認したいと思います。

ベストアンサー1

このコード

while True:
   b = f1.read(bsize)
   if b:
       f2.write(b)
   else:
       break

している順番に読み取りと書き込み - anyが与えられたら、bsize最初のbsizeバイトを読み取り、ターゲットファイルに書き込み、次に2番目のバイトを読み取り、ターゲットファイルbsizeに追加します。

オペレーティングシステムは以下を介してそれをバッファリングします。ページキャッシュ、コメントに記載されている@StephenKittなどの入力データを事前に読み込み、事前にバッファリングすることもできます。したがって、物理ディスクへのデフォルトのIO呼び出しは、最終的に述べた1MBのより大きなチャンクに統合されます。

bsizeパフォーマンスに見られる小さな違いは、小さなプロセスを使用するときに実際にデータを移動するためにカーネルに対してより多くのシステムコールを実行する必要があるため、ほぼ完全に発生します。

したがって、テストコードを変更する際に大きな違いを見ることができない理由はほとんど明らかですbsizeが、システムに関する詳細がなければ確かに知ることは実際には不可能です。

もっと...

あなたがやっていることは実際に同じです

dd if=random.20g1 of=random.20g1.dest bs=8192

実際に使用するには、ddディスクIOをテストするためにさらに多くのことを行うことができます(次を見てください)。マニュアルページ- たとえば、直接IOを使用してページキャッシュをバイパスできますが、最終的に実行できるIOテストは連続的であるddため、非常に制限的です。 ddあなたに見せる最高IOパフォーマンスは優れていますが、実際のワークロードを大量にシミュレートできないため、IOパフォーマンスの欠点があります。

グリッド操作が実際に使用しているIOパターンについてさらに決定する必要があります。つまり、テストのように順次読み取り/書き込みを実行していますか、それとも実行していますか?ランダムIOを実行する前に、ファイル内の検索場所を有効な任意の場所に読み書きしますか?ランダムIO操作は、ファイルシステムと基本ディスクハードウェア(特にローテーションディスク)の需要を高めます。毎秒数百MBのストリーミング順次IOを送信できるシステムは、非常に少ない量に削減できます。キロバイト1秒あたりのランダムな小規模IO操作です。特に遅い5,000RPM SATAディスクを使用している場合。

ファイルシステムとRAIDアレイを理解していない人がストレージを設定すると、状況が本当に悪くなる可能性があります。 1MBファイルシステムのブロックサイズへの言及は、「より大きいほど速い」という誤ったパラダイムでストレージシステムの設定にアクセスしているようです。

「より大きいものが常に高速です」パラダイムをRAID 5/6アレイと任意の小さなIOチャンク(グリッド操作が実行しているように見えるもの)と組み合わせると、IOパフォーマンスが著しく低下する可能性があります。

straceLinuxで利用可能操作で実行された実際のシステムコールを取得します。lseek、、、writeなどreadpwrite呼び出しを見つけますpread。これは、タスクが実行する実際のIOパターンを伝えます。

IOパターンがある場合は、そのパターンを密接に複製するツールを使用して、そのパターンで実際のストレージパフォーマンスをテストしてベンチマークできます。任意の場所に書き込み/書き込みが可能なツールが必要な場合があります。もう一度Linuxを想定すると、から始めることができますfio。ランダム読み取り/書き込みオプションも使用できます。

おすすめ記事