IOMeter-どの値でテストする必要がありますか？
ある意味、これは文字列の質問だと思いますが、「これはほとんどの状況に当てはまる」という答えがあっても、それが何であるかわかりません。
私はSAN、HP P4000を評価しています。IOMeterを使用してベンチマークを実行し、何ができるかを確認したいと思います。
ただし、ブロックサイズ、読み取り/書き込み分割、ランダム/シーケンシャル分割のどの組み合わせがさまざまな使用法に適用できるかわかりません。
たとえば、Exchangeアクティビティ、SQLアクティビティ、一般的なVMアクティビティなど）をどのようにシミュレートしますか。
ワーカーを追加してさまざまな設定で緩める方法を知っていますが、どの設定を使用する必要がありますか？
ありがとう。
ExchangeおよびSQLアクティビティは、頻繁に発生する、スケールの小さいIO/Opsの終わりになりがちです。添付ファイルが書き込まれる/プルされるため、Exchangeにはかなりの数の大きなI/Oバーストがあります。バックアップ間隔と長時間実行されるクエリも実際に問題を引き起こす可能性があり、おそらくピークI/Oインスタンスです。 Exchange Online DefragはExchangeのIOピークであり、SQLBackupsはSQLサーバーのI/Oピークです。
Exchange Online Defragには、多くのI/O操作が含まれますが、スループットはそれほど高くないため、平均転送サイズは小さく、512bは小さく、それらは多くあります。読み取り/書き込みの比率は大きく異なりますが、適切に保守されたExchange DBの場合、ほとんどが読み取りである必要があります。これはかなりランダムになりますが、面白く保つのに十分なシーケンシャルアクセスがあります（正確な比率はありません）。
SQLバックアップにはさまざまなサイズがありますが、オンラインとは異なり、デフラグのスループットも実際には高くなります。 512bから4kbの転送サイズの組み合わせを計画します。読み取り/書き込みの比率は、データがどこに到達するかによって異なります。書き込みは非常に高速になる可能性がありますが、（バックアップスクリプトによっては）ほぼ完全にシーケンシャルです。読み取りは100％ランダムになります。
一般VMアクティビティはVMの内容によって異なります。ExchangeまたはSQLが含まれている場合は、それを監視します。一般的に、WebやCIFS共有は、彼らが何をしているかによって異なります; CADエンジニアは、購買オフィスの担当者でいっぱいのオフィスとは非常に異なるアクセスパターンを持っています。 VMアクティビティ '。VMに実際にあるものを計画する必要があります。
Iometerを使用したストレージシステムのパフォーマンス分析： http://communities.vmware.com/docs/DOC-3961
SQLServerの観点から
SQL Serverボックスでは、MDF、NDF、LDF、およびTEMPDBファイルを保存する場所に応じて、次のパラメーターを使用してディスクをテストすることをお勧めします。
すべてのディスク（MDF、NDF、LDF、TEMPDB）
- 8KiB転送リクエストサイズ
- 80％の読み取り率
- 95％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
シリアルに書き込まれたディスク（LDF、TEMPDB）
- 8KiB転送リクエストサイズ
- 20％の読み取り率（ログとTEMPDBは書き込みが集中します）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
シリアル読み取りディスク（MDF、NDF）
64KiBエクステント読み取り
- 64KiB転送リクエストサイズ
- 80％の読み取り率（MDFおよびLDFファイルは主にから読み取られます）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
128KiB先読み
- 128KiB転送リクエストサイズ
- 80％の読み取り率（MDFおよびLDFファイルは主にから読み取られます）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
256KiB先読み
- 256KiB転送リクエストサイズ
- 80％の読み取り率（MDFおよびLDFファイルは主にから読み取られます）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
512KiB先読み
- 512KiB転送リクエストサイズ
- 80％の読み取り率（MDFおよびLDFファイルは主にから読み取られます）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
1024 KiB先読み（Enterprise Edition）
- 1024KiB転送リクエストサイズ
- 80％の読み取り率（MDFおよびLDFファイルは主にから読み取られます）
- 0％ランダム読み取り
- ランプアップ時間10（ストレージキャッシュを回避するため）
- 最大ディスクサイズ（4'000'000セクター= 2 GiB）
ランダム読み取りの割合を変えて、結果が変わるかどうかを確認できますが、上記の値はかなり良い出発点であることがわかりました。
読み取り/書き込みおよびシーケンシャル/ランダムのI/Oサイズの組み合わせをテストします。 SQLに重点を置いた展開の場合、シーケンシャルI/O用に8KB、64 KB、128 KB、256 KB、および1024のI/Oサイズを含めるようにしてください。 （SQL Server Enterprise Editionを実行している場合、先読みは最大1024 KBになる可能性があります）。ランダムI/Oの場合、通常は8 KB I/Oのみに焦点を当てることが安全です。
SQLServerでの低速ディスクI/Oのトラブルシューティング（ブログMSDN）
ディスクのパフォーマンスが低下していると思われる場合は、内部DMVをパフォーマンスモニターコレクションと組み合わせて使用して、ディスクI/Oサブシステムの状態とSQLServerのパフォーマンスの低下による遅延を正確に把握できます。
SQL Server Perfmon（パフォーマンスモニター）のベストプラクティス（BrentOzar）
[パフォーマンスオブジェクト]ドロップダウンで、[物理ディスク]を選択し、[％ディスク時間]カウンターを選択します。再び右側のウィンドウに、複数のインスタンスが表示されていることに注意してください。今回は、物理ディスクごとに1つ取得します。パフォーマンスの観点から、物理ディスクとは、コンピュータの管理のディスク管理ツールに表示される1つのディスクを意味します。 1つの物理ディスクに複数のパーティションがあり、それぞれに独自のドライブ文字が付いている場合がありますが、パフォーマンスチューニングのために、1つの物理ディスクがどの程度機能しているかを知りたいと思います。
この1つの「物理ディスク」には、RAIDシステムのように、実際の物理ドライブが多数ある場合があります。ただし、WindowsはRAIDアレイ内のドライブの数を正確に把握するのに十分なほどスマートではないため、ここでは「物理ディスク」という用語は少し誤解を招く可能性があります。
SQL Server（SQLSkills）内からIOサブシステムの待機時間を調べる方法
今日のほとんどのSQLServerはI/Oバウンドです。これは、DBAとこの分野のコンサルタントによって一般的に合意された声明です。これは、サーバーパフォーマンスの主な要因は、I/O操作を迅速に実行できることを意味します。 I/Oサブシステムが要求に対応できない場合、SQLServerのワークロードでパフォーマンスの問題が発生します。
さて、多くの人が陥る落とし穴の1つは、I/Oサブシステムのレイテンシーの増加とI/Oサブシステムのパフォーマンスの低下を同一視することです。多くの場合、これはまったく当てはまりません。通常、I/Oサブシステムは、設計されたI/Oワークロードが発生しているときは正常に動作しますが、I/OワークロードがI/Oサブシステムの設計ポイントを超えて増加するとパフォーマンスのボトルネックになります。 I/Oワークロードの増加が問題の原因であり、I/Oサブシステムではありません。1000IOPS（1秒あたりのI/O操作）をサポートするようにI/Oサブシステムを設計し、適切なI /を使用していることを確認する場合Oサイズとワークロード特性はランダムIOPSの数で定義するのが理にかなっています）、SQLServerは2000IOPSをプッシュしようとしているため、パフォーマンスが低下します。