3

せっかちな場合は、下の「QUESTION」の見出しにスキップしてください。

環境

私は Unix (のような) システム管理とインフラストラクチャ開発に取り組んでいますが、私の質問はプログラマーによって最もよく答えられると思います :o)

私がやりたいことは、iozone を使用してファイル システム (プレーン、ボリューム管理、仮想化、暗号化など) のベンチマークを行う方法を学ぶことです。演習として、それぞれ vfat、ntfs、ext3、ext4、xfs でフォーマットされた私のスラッグ ( http://www.nslu2-linux.org/ ) でシステム ディスクとして使用することを意図した USB ペンドライブのベンチマークを行いました。このテストでは、以下に掲載されているいくつかの驚くべき結果が得られました。しかし、結果が私を驚かせた理由は、私がまだiozoneに不慣れで、数字を解釈する方法を本当に知らないからかもしれません. したがって、この投稿。

私のテストでは、iozone は 11 の異なるファイル操作でベンチマークを実行しましたが、1 つのレコード サイズ (4k、テストしたすべてのファイル システムのブロック サイズに一致) と 1 つのファイル サイズ (512MB) のみでした。もちろん、ファイル システムのレコード サイズとファイル サイズは一方的なものであるため、テストにはある程度の偏りが残ります。とにかく、ファイル操作を以下にリストし、それぞれに簡単な説明を付けます。

  • 初期書き込み: 新しいデータをディスクに順次書き込み、通常のファイル使用
  • 書き換え: 新しいデータを既存の順次、通常のファイル使用法に追加
  • read: 順次読み取りデータ、通常のファイル使用
  • re-read: データを順次再読み込み (バッファテストか何か?)
  • 逆読み:???
  • ストライド読み取り: ???
  • ランダム読み取り: 非順次読み取り、通常はデータベースの使用
  • ランダム書き込み: 非順次書き込み、通常はデータベースの使用
  • pread: 特定の位置でのデータの読み取り - データベースの索引付け用?
  • pwrite: 特定の位置へのデータの書き込み - データベースの索引付け用?
  • 混合ワークロード: (明らか)

これらの操作のいくつかは単純に見えます。最初の書き込み、書き換え、読み取りはすべて通常のファイル処理に使用され、特定のブロックに到達するまでポインターをシークさせ、(多くの場合、多くのブロックを介して) 順次読み取りまたは書き込みを行い、断片化のために少し前にジャンプする必要がある場合があると思いますファイル。再読み取りテストの唯一の目的は (私は推測します)、バッファー テストです。並行して、ランダムな読み取り/書き込みは典型的なデータベース操作であり、たとえばテーブルを結合する場合など、データベース レコードを収集する同じファイル内でポインターを場所から場所へジャンプする必要があります。

質問は何ですか?

ここまでは順調ですね。上記の仮定はかなり一般的な知識のように見えますが、修正していただければ幸いです。さて、本当の質問です。なぜ逆読みをするのでしょうか? ストライドリードとは?また、「位置」操作の pread と pwrite は、インデックス付きデータベースで使用されると聞いていますが、単にインデックスをメモリに保持しないのはなぜでしょうか? それとも、それが実際に起こっていることであり、特定のインデックスが与えられると、レコードの正確な位置にジャンプするのに pread が役立ちますか? pread/pwrite を他に何に使用しますか?

要約すると、現時点では、iozone の結果をやや中途半端にしか解釈できないと感じています。ランダム操作の数が多いとデータベースに適したファイルシステムになる理由は多かれ少なかれわかっていますが、ファイルを逆順に読み取る必要があるのはなぜですか。これらの操作の典型的なアプリケーションの用途は何ですか?

ボーナス質問

それを尋ねたので、ここにボーナスの質問があります。特定のファイル システムの管理者として、insightfull プログラマーから私のファイル システム ベンチマークを解釈する方法を感謝して学びました ;) - ファイル システムの実際の使用を分析する方法について提案がある人はいますか? ファイル システムのレコード (ブロック) サイズを試すのは簡単ですが、時間がかかります。また、特定のファイル システム内のファイルのサイズと分布に関しては、「検索」が私の友人です。しかし、read()、pwrite() などの実際のファイル システム呼び出しのカウントを取得するにはどうすればよいでしょうか?

また、プロセッサの能力や RAM の容量と速度の役割など、他のリソースがファイル システムのテスト結果に与える影響についてコメントをいただければ幸いです。たとえば、266 MHz ARM Intel XScale プロセッサと 32/8 のスラッグでペンドライブを使用したい場合、1.66Ghz Atom プロセッサと 2 ギガの DDR2 RAM を搭載したマシンでこのテストを行うと、どのような違いがありますか? MB SD/フラッシュ RAM?

建築志向のドキュメント?

私は自分自身をあまり繰り返したくないので、他の人にも尋ねたくないので、これらの質問に手短に答えられない場合は、詳細なドキュメントへのリンクをいただければ幸いです。上記のファイル操作が実際に何をするかを説明している (そのために API を参照することもできます) が、このドキュメントはアーキテクチャを考慮したものであり、つまり、これらの操作が実際のアプリケーションで通常どのように使用されるかを説明しています。

試験結果

右。私はかなり控えめな USB ペンドライブ ファイル システム テストの結果を約束しました。私の主な期待は、一般的に書き込みの結果が悪いことでした(フラッシュドライブは、その性質上、実際に管理しているファイルシステムよりも大きなブロックサイズを持っていることが多いため、小さな変更を書き込むには、比較的大量の変更されていないデータを書き換える必要があります) )、読み取り結果は良好です。主なポイントは次のとおりです。

  • vfat はすべての操作で非常にうまく機能しました。機能が不足しているため、多くの簿記が不要になっていると思います。

  • ntfs は、書き換え (追加) 操作と読み取り操作が苦手なため、通常のファイル操作には適していません。また、preread 操作が苦手なため、インデックス付きデータベースの候補としては適していません。

  • 驚くべきことに、ext3 と ext4 は、すべての操作でわずかに優れていますが、最初の書き込み、書き換え、読み取り、ランダム書き込み、および pwrite 操作がうまくいかないため、定期的なファイルの使用や頻繁に更新されるデータベースには適していません。ただし、ext4 はランダムな読み取りとプリロードのマスターであるため、ある程度静的なデータベース (?) の優れた候補になります。ext3 と ext4 の両方が、あいまいなリバース読み取り操作とストライド読み取り操作で高いスコアを獲得しています。

  • テスト全体で卓越した勝者となったのは xfs で、唯一の弱点はリバース リードのようです。最初の書き込み、書き換え、読み取り、ランダム書き込み、および pwrite では、それは最高のものの 1 つであり、通常のファイルの使用および (頻繁に更新される) データベースの優れた候補となっています。再読み取り、ランダム読み取り、および先読みでは次点であり、(ある程度静的な) データベースの候補として適しています。それはまた、ストライド読み取りにも適しています-それが何を意味するにせよ!

これらの結果の解釈に関するコメントは大歓迎です! 番号は下にリストされています (長さのために多少省略されています)。ファイル システム タイプ、すべて標準の 4GB Verbatim ペンドライブ (オレンジ色 ;)) でテスト済み暗号化されたスワップを使用します(ええ、わかっています。64ビットLinuxをインストールし、スワップをクリアのままにしておく必要があります!)。

よろしく、トルステン

PS。これを書いた後、明らかに、Debian NSLU2 ディストリビューションは xfs をサポートしていないことがわかりました。しかし、私の質問はまだ残っています!

--- vfat ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:23:57 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   12864.82 KB/sec
Parent sees throughput for  1 initial writers   =    3033.39 KB/sec

Children see throughput for  1 rewriters    =   25271.86 KB/sec
Parent sees throughput for  1 rewriters     =    2876.36 KB/sec

Children see throughput for  1 readers      =  685333.00 KB/sec
Parent sees throughput for  1 readers       =  682464.06 KB/sec

Children see throughput for 1 re-readers    =  727929.94 KB/sec
Parent sees throughput for 1 re-readers     =  726612.47 KB/sec

Children see throughput for 1 reverse readers   =  458174.00 KB/sec
Parent sees throughput for 1 reverse readers    =  456910.21 KB/sec

Children see throughput for 1 stride readers    =  351768.00 KB/sec
Parent sees throughput for 1 stride readers     =  351504.09 KB/sec

Children see throughput for 1 random readers    =  553705.94 KB/sec
Parent sees throughput for 1 random readers     =  552630.83 KB/sec

Children see throughput for 1 mixed workload    =  549812.50 KB/sec
Parent sees throughput for 1 mixed workload     =  547645.03 KB/sec

Children see throughput for 1 random writers    =   19958.66 KB/sec
Parent sees throughput for 1 random writers     =    2752.23 KB/sec

Children see throughput for 1 pwrite writers    =   13355.57 KB/sec
Parent sees throughput for 1 pwrite writers     =    3119.04 KB/sec

Children see throughput for 1 pread readers     =  574273.31 KB/sec
Parent sees throughput for 1 pread readers  =  572121.97 KB/sec

--- NTFS ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 13:59:37 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   11153.75 KB/sec
Parent sees throughput for  1 initial writers   =    2848.69 KB/sec

Children see throughput for  1 rewriters    =    8723.95 KB/sec
Parent sees throughput for  1 rewriters     =    2794.81 KB/sec

Children see throughput for  1 readers      =   24935.60 KB/sec
Parent sees throughput for  1 readers       =   24878.74 KB/sec

Children see throughput for 1 re-readers    =  144415.05 KB/sec
Parent sees throughput for 1 re-readers     =  144340.90 KB/sec

Children see throughput for 1 reverse readers   =   76627.60 KB/sec
Parent sees throughput for 1 reverse readers    =   76362.93 KB/sec

Children see throughput for 1 stride readers    =  367293.25 KB/sec
Parent sees throughput for 1 stride readers     =  366002.25 KB/sec

Children see throughput for 1 random readers    =  505843.41 KB/sec
Parent sees throughput for 1 random readers     =  500556.16 KB/sec

Children see throughput for 1 mixed workload    =  553075.56 KB/sec
Parent sees throughput for 1 mixed workload     =  551754.97 KB/sec

Children see throughput for 1 random writers    =    9747.23 KB/sec
Parent sees throughput for 1 random writers     =    2381.89 KB/sec

Children see throughput for 1 pwrite writers    =   10906.05 KB/sec
Parent sees throughput for 1 pwrite writers     =    1931.43 KB/sec

Children see throughput for 1 pread readers     =   16730.47 KB/sec
Parent sees throughput for 1 pread readers  =   16194.80 KB/sec

--- ext3 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 16:05:27 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/1/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    3704.61 KB/sec
Parent sees throughput for  1 initial writers   =    3238.73 KB/sec

Children see throughput for  1 rewriters    =    3693.52 KB/sec
Parent sees throughput for  1 rewriters     =    3291.40 KB/sec

Children see throughput for  1 readers      =  103318.38 KB/sec
Parent sees throughput for  1 readers       =  103210.16 KB/sec

Children see throughput for 1 re-readers    =  908090.88 KB/sec
Parent sees throughput for 1 re-readers     =  906356.05 KB/sec

Children see throughput for 1 reverse readers   =  744801.38 KB/sec
Parent sees throughput for 1 reverse readers    =  743703.54 KB/sec

Children see throughput for 1 stride readers    =  623353.88 KB/sec
Parent sees throughput for 1 stride readers     =  622295.11 KB/sec

Children see throughput for 1 random readers    =  725649.06 KB/sec
Parent sees throughput for 1 random readers     =  723891.82 KB/sec

Children see throughput for 1 mixed workload    =  734631.44 KB/sec
Parent sees throughput for 1 mixed workload     =  733283.36 KB/sec

Children see throughput for 1 random writers    =     177.59 KB/sec
Parent sees throughput for 1 random writers     =     137.83 KB/sec

Children see throughput for 1 pwrite writers    =    2319.47 KB/sec
Parent sees throughput for 1 pwrite writers     =    2200.95 KB/sec

Children see throughput for 1 pread readers     =   13614.82 KB/sec
Parent sees throughput for 1 pread readers  =   13614.45 KB/sec

--- ext4 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 17:59:26 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/2/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    4086.64 KB/sec
Parent sees throughput for  1 initial writers   =    3533.34 KB/sec

Children see throughput for  1 rewriters    =    4039.37 KB/sec
Parent sees throughput for  1 rewriters     =    3409.48 KB/sec

Children see throughput for  1 readers      = 1073806.38 KB/sec
Parent sees throughput for  1 readers       = 1062541.84 KB/sec

Children see throughput for 1 re-readers    =  991162.00 KB/sec
Parent sees throughput for 1 re-readers     =  988426.34 KB/sec

Children see throughput for 1 reverse readers   =  811973.62 KB/sec
Parent sees throughput for 1 reverse readers    =  810333.28 KB/sec

Children see throughput for 1 stride readers    =  779127.19 KB/sec
Parent sees throughput for 1 stride readers     =  777359.89 KB/sec

Children see throughput for 1 random readers    =  796860.56 KB/sec
Parent sees throughput for 1 random readers     =  795138.41 KB/sec

Children see throughput for 1 mixed workload    =  741489.56 KB/sec
Parent sees throughput for 1 mixed workload     =  739544.09 KB/sec

Children see throughput for 1 random writers    =     499.05 KB/sec
Parent sees throughput for 1 random writers     =     399.82 KB/sec

Children see throughput for 1 pwrite writers    =    4092.66 KB/sec
Parent sees throughput for 1 pwrite writers     =    3451.62 KB/sec

Children see throughput for 1 pread readers     =  840101.38 KB/sec
Parent sees throughput for 1 pread readers  =  831083.31 KB/sec

--- xfs ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:47:49 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   21854.47 KB/sec
Parent sees throughput for  1 initial writers   =    3836.32 KB/sec

Children see throughput for  1 rewriters    =   29420.40 KB/sec
Parent sees throughput for  1 rewriters     =    3955.65 KB/sec

Children see throughput for  1 readers      =  624136.75 KB/sec
Parent sees throughput for  1 readers       =  614326.13 KB/sec

Children see throughput for 1 re-readers    =  577542.62 KB/sec
Parent sees throughput for 1 re-readers     =  576533.42 KB/sec

Children see throughput for 1 reverse readers   =  483368.06 KB/sec
Parent sees throughput for 1 reverse readers    =  482598.67 KB/sec

Children see throughput for 1 stride readers    =  537227.12 KB/sec
Parent sees throughput for 1 stride readers     =  536313.77 KB/sec

Children see throughput for 1 random readers    =  525219.19 KB/sec
Parent sees throughput for 1 random readers     =  524062.07 KB/sec

Children see throughput for 1 mixed workload    =  561513.50 KB/sec
Parent sees throughput for 1 mixed workload     =  560142.18 KB/sec

Children see throughput for 1 random writers    =   24118.34 KB/sec
Parent sees throughput for 1 random writers     =    3117.71 KB/sec

Children see throughput for 1 pwrite writers    =   32512.07 KB/sec
Parent sees throughput for 1 pwrite writers     =    3825.54 KB/sec

Children see throughput for 1 pread readers     =  525244.94 KB/sec
Parent sees throughput for 1 pread readers  =  523331.93 KB/sec
4

3 に答える 3

3

ファイルシステムのパフォーマンスを深く掘り下げる必要があったのは、Windows システム上だけでした。使用しているOS /ファイルシステムに関係なく、一般的な原則が適用されます...

なぜ逆読みをするのでしょうか?

プログラムが実行されると、ブロック 987654 が読み取られ、そのデータを使用してブロック 123456 が必要であると判断されます。ピッキング操作は、テーブル 1 の順序 (テーブル 2 の順序の逆) で発生する場合があります。

2 つのキーを使用する場合、同様の状況が単一のテーブル選択で発生する可能性があります。

ストライドリードとは?

N 番目のブロックごとに読み取ります。ブロック 12345600、ブロック 12345700、ブロック 12345800 の読み取りは 100 のストライドです。多くの列や大きな列を持つテーブルを想像してください。そのテーブルには、データを保持するためにいくつかのファイル システム ブロックを必要とする行が含まれている場合があります。通常、データベースはこのデータを各行のレコードに編成し、各レコードはいくつかの連続したファイルシステム ブロックを占有します。データベースの行が 10 個のファイル システム ブロックを占有し、2 つの列を選択している場合、その 10 ブロック レコードの 1 番目と 6 番目のブロックのみを読み取る必要がある場合があります。次に、クエリでブロック 10001、10006、10011、10016、10021、10026 (ストライド 5) を読み取る必要があります。

また、「位置」操作の pread と pwrite は、インデックス付きデータベースで使用されると聞いていますが、単にインデックスをメモリに保持しないのはなぜでしょうか?

インデックスのサイズが、RAM 使用量の妥当な量を超える場合があります。または、以前の使用で他のインデックスまたはデータを RAM に呼び出したため、未使用のインデックスがファイルシステム/db キャッシュから削除されました。

それとも、それが実際に起こっていることであり、特定のインデックスが与えられると、レコードの正確な位置にジャンプするのに pread が役立ちますか? うん、それはあなたのデータベースがやっていることかもしれません。

pread/pwrite を他に何に使用しますか?

一部のデータ ファイルには、事前定義された「興味深い」場所があります。これは、DB 実装に応じて、B ツリー インデックスのルート、テーブル ヘッダー、ログ/ジャーナル テール、またはその他のものである可能性があります。pread/rwrite は、一様にランダムな場所の組み合わせではなく、セットの特定の場所に繰り返しホッピングするパフォーマンスをテストしています。

リンク?

すべてのメインストリーム OS には、すべての OS ファイルシステム操作をキャプチャできるシステムユーティリティが存在します。これらは、*NIX システムでは DTRACE、pTAP、または pTRACE と呼ばれる可能性があると思います。これらのモニターからの (インテリジェントにフィルター処理された) 大量のデータを使用して、システム内のディスク アクセス パターンを確認できます。

次に、一般的な経験則は、Db の使用には、わいせつな量の RAM が役立つということです。次に、すべてのインデックスが常に RAM に存在します。

于 2012-06-05T14:54:16.153 に答える
1

申し訳ありませんが、お問い合わせいただいた特定のシステム コールに関する情報を追加することはできません。そのため、代わりにいくつかの独断的なコンテンツを追加します...

私の意見では、iozone はあまり興味深いベンチマーク ツールではありません。また、さまざまなシステム コールのプロファイリングもあまり面白くないと思います。

重要なのは、ファイル システムが実世界でどのように機能するかです。ただし、実際のシナリオでのベンチマークは非常に時間がかかる場合があります。たとえば、有効なテスト環境を作成するには時間がかかる場合があります。そのため、ベンチマーク ツールが役立ちます。ただし、ベンチマーク ツールは、実際のアプリケーションにできるだけ近い方法で動作できる必要があります。また、関連するハードウェア/ソフトウェアの限界が調査されるように、ベンチマーク ツールが残忍な方法で動作するのは通常は良いことです。

これらの要件を満たす 2 つのベンチマーク ツールは、fioと Oracle のorionです。両方のツールを使用すると、読み取りと書き込みを適切に組み合わせて使用​​するベンチマークを指定し、ベンチマークをどの程度並列に実行するかを指定するのは比較的簡単です。また、デバイス レベルと FS レベルの両方のベンチマークを実行できます。特定のファイル システムのオーバーヘッドなしでストレージ機器のベンチマークを実行したい場合があるため、これは便利です。Orion と比較して、fio には動的なメーリング リストがあり、良い回答が得られる可能性が非常に高いという利点があります (Orion のメーリング リストは見つかりませんでした)。

于 2012-06-05T18:39:24.370 に答える
1

あなたの質問の2つの部分について、背景を説明できます。「後方読み取り」テストは、一部の機械工学アプリケーションの I/O 動作を観察した結果として導入されました。これらのアプリケーションは、頻繁にディスクから順方向に読み取り、次に逆方向に読み取ります。これは(線形代数の) 前方置換と後方置換に関連している、または磁気テープ ドライブに依存する元の実装に関連しているという憶測がありました。

ストライド アクセスに関しては、これは多くの地震探査アプリケーション (深さおよび/または時間移動 IIRC) の一般的な I/O パターンでした。「後方読み取り」シナリオの場合と同様に、これもこれらのアプリケーションの I/O 動作を観察した後に導入されました。

于 2015-11-02T19:42:02.563 に答える