4

私たちは毎日数千人のユーザーにサービスを提供するアプリケーションに取り組んでいます（それらの90％は勤務時間中にアクティブになり、勤務時間中は常にシステムを使用します）。このシステムの主な目的は、複数のデータベースにクエリを実行し、データベースからの情報を組み合わせて、ユーザーへの単一の応答にすることです。ユーザー入力にもよりますが、ユーザー数が1000人のシステムでは、クエリの負荷は1秒あたり約500クエリになる可能性があります。これらのクエリの80％は読み取りクエリです。

ここで、SQL Server Profilerツールを使用してプロファイリングを実行し、読み取りクエリに対して平均で最大300の論理読み取りを取得しました（書き込みクエリについてはまだ気にしませんでした）。これは、1,000人のユーザーの場合、1秒あたり15万回の論理読み取りに相当します。完全な本番システムには、最大10,000人のユーザーがいると予想されます。

これらのデータベースのストレージの実際の読み取り要件を見積もるにはどうすればよいですか？実際の物理的な読み取りはそれよりはるかに少ないと確信していますが、どうすればそれを見積もることができますか？もちろん、実稼働環境はまだ存在しないため、実稼働環境で実際に実行することはできません。ハードウェアの担当者に、システムに必要なIOPSを伝えて、何をすべきかを知らせる必要があります。買う。

以前の回答で提案されたHPサイジングツールを試しましたが、実際のパフォーマンスの見積もりではなく、HP製品のみを提案しています。任意の洞察をいただければ幸いです。

編集：メインの読み取り専用データセット（ほとんどのクエリが送信される場所）は、ディスク上の2桁（桁違いに4ギガ）です。これはおそらく、論理読み取りと物理読み取りに大きく影響します。この比率を取得する方法についての洞察はありますか？

4

2 に答える 2

2

ディスクI/Oの需要は、次のような多くの要因に基づいて大きく異なります。

  • すでにRAMにあるデータの量
  • スキーマの構造（インデックス、行幅、データ型、トリガーなど）
  • クエリの性質（結合、複数の単一行と行範囲など）
  • データアクセス方法論（ORMとセット指向、単一コマンドとバッチ処理）
  • 読み取りと書き込みの比率
  • ディスク（データベース、テーブル、インデックス）の断片化ステータス
  • SSDと回転メディアの使用

これらの理由から、本番ディスクの負荷を見積もる最良の方法は、通常、小さなプロトタイプを作成してベンチマークすることです。可能であれば、本番データのコピーを使用してください。それ以外の場合は、データ生成ツールを使用して、同様のサイズのDBを構築します。

サンプルデータを用意して、期待する種類のクエリを組み合わせて生成するシンプルなベンチマークアプリを作成します。必要に応じてメモリサイズをスケーリングします。

Windowsパフォーマンスカウンターを使用して結果を測定します。最も有用な統計は、物理ディスクに関するものです。転送あたりの時間、1秒あたりの転送、キューの深さなどです。

次に、これらの結果にいくつかのヒューリスティック（「エクスペリエンス」とも呼ばれます）を適用し、それらを本番I/O要件のファーストカット見積もりに外挿することができます。

プロトタイプを絶対に作成できない場合は、初期測定に基づいて知識に基づいた推測を行うことは可能ですが、それでも作業が必要です。手始めに、統計をオンにします。

SET STATISTICS IO ON

テストクエリを実行する前に、RAMキャッシュをクリアします。

CHECKPOINT
DBCC DROPCLEANBUFFERS

次に、クエリを実行し、物理読み取り+先読み読み取りを調べて、物理ディスクのI/O要求を確認します。最初にRAMキャッシュをクリアせずにいくつかの組み合わせを繰り返して、キャッシュがどの程度役立つかを把握します。

そうは言っても、IOPSだけをターゲットとして使用することはお勧めしません。SANベンダーとITマネージャーはIOPSを気に入っているようですが、これらはディスクサブシステムのパフォーマンスの非常に誤解を招く指標です。例として、シーケンシャルI / Oからランダムに切り替えると、成果物のIOPSに40：1の違いが生じる可能性があります。

于 2012-01-03T04:14:07.093 に答える
0

確かに、論理読み取りから見積もりを導き出すことはできません。このカウンターは、物理的なカウンターの量が不明であることが多く、これらの各アクセスのCPUコストも不明であるため、実際にはそれほど役に立ちません。私はこの数をまったく見ていません。

物理IOを表示する仮想ファイル統計を収集する必要があります。例：http ：//sqlserverio.com/2011/02/08/gather-virtual-file-statistics-using-t-sql-tsql2sday-15/

「仮想ファイル統計SQLサーバー」のためのグーグル。

バッファプールのキャッシュヒット率が同じままであると想定する場合にのみ、ユーザー数からIOを推定できることに注意してください。これを見積もるのははるかに困難です。基本的に、フルロードで使用するページのワーキングセットを見積もる必要があります。

バッファプールが常にすべてのホットデータを取得できるようにすることができれば、基本的に読み取りなしで生きることができます。次に、書き込みをスケーリングするだけで済みます（たとえば、SSDドライブを使用）。

于 2012-01-02T19:26:13.077 に答える