このブログサイトの主な焦点は、SQLServer環境でのパフォーマンスです。パフォーマンスはデータベースとアプリケーションの設計から始まると主張する人もいるかもしれません。ただし、適切なリソースを利用できることが、優れたパフォーマンスのために不可欠であると主張することもできます。適切なリソース（CPUモデル、メモリの量、ストレージの種類）に関するすべての議論で、キャパシティプランニングの行為を無視することがあります。私たちが持っているデータを使用する 必要なものについて十分な情報に基づいて決定を下す 。キャパシティプランニングは、必要なディスクスペースを把握するだけでなく、SQLServerインスタンスがワークロードを処理するために利用可能でなければならないリソースも含みます。
新規または既存？
新しいソリューションのキャパシティプランニングは非常に注意が必要です。ビジネスから収集した情報に基づいて、ワークロードに関する見積もりを作成する必要があります。これは、最初の月、最初の6か月、および最初の年にどのくらいのデータが期待されるかについて、難しい質問をする必要があることを意味します。新しいソリューションが登場するとき、これは多くの場合、ビジネスが考えている最後のことであるため、漠然とした答えが得られることがよくあります。新しいソリューションの場合、あなたは本当に最善の推測努力をしました。正確な数字を取得しようとして髪を抜かないでください。
ソリューションがベンダーからのものである場合は、必要なスペースと必要なリソースの両方に関する計画の推奨事項をベンダーに依頼する必要があります。確かに、彼らはそのデータを持っていないかもしれませんが、あなたはあなたが求めていないものを手に入れることができません。試してみるのは決して痛いことではありません。
[ボーナス：ベンダーが提供する情報を持っていない場合、システムが数か月稼働した後、使用しているハードウェアなどのデータをベンダーに送信すると便利です。 、およびワークロードはどのように見えますか？ 20ページの記事である必要はありませんが、フィードバックにより、今後さらに積極的になる方向に進む可能性があります。]
既存のソリューションに関して、パフォーマンスの問題がある場合、またはハードウェアのアップグレードを検討している場合は、新しい環境を計画するために、現在の環境に関する情報を取得する必要があります。
ストレージ
金額の計画 必要なストレージの量はかなり単純で、事前に計画を立てる必要があります。プロアクティブなSQLServerヘルスチェックの記事では、ディスクスペースの監視について説明し、ファイル情報をキャプチャするためのクエリを含めています。このクエリは、インスタンスのデータベースファイルのサイズと使用されているスペースをキャプチャします。このデータを時間の経過とともにトレンド分析することが不可欠であり、それは数週間を意味するものではありません。アプリケーションの使用パターンが変わる可能性があるため、ファイルが数か月、場合によっては最大1〜2年でどのように変化するかを確認しようとしています。この情報は簡単に取得でき、保存するスペースもほとんど必要ありません。また、ストレージを調達する際の参照として非常に役立ちます。システムの成長に関する定量的なデータを提供できれば、後で要求するよりも、必要なスペースを前もって取得できる可能性がはるかに高くなります。また、スペースを要求するときは、計算にtempdbを含めるようにしてください。
ハードウェアリソース
CPU
CPUパフォーマンスの最適化は、使用しているCPUの数だけでなく、モデルとワークロードも考慮する必要があります（たとえば、大規模な並列クエリを使用するデータウェアハウスとシリアルクエリを使用するOLTP）。この情報とGlennの少しの助けを借りて、サーバーに最適なプロセッサを決定できます。 SQL Serverのエディションに基づいて、ライセンスのコストと制限を考慮することを忘れないでください！
メモリ
メモリは比較的安価であり、サーバーが保持できる最大量のメモリを常に購入することをお勧めします。メモリからのデータの読み取りは、ディスクからの読み取りよりも大幅に高速であるため、メモリに収まるデータが多いほど優れています。データベース全体が持っていないことに注意してください メモリに収まるように。必要なのは、メモリに収まるデータのワーキングセットだけです。 2TBのデータベースを考えてみましょう。 OLTPシナリオでは、2TBすべてが毎日アクセスされる可能性はほとんどありません。通常、アクセスされるのは最近のデータのみです。おそらく過去30日または60日だけです。これが、メモリに収まる必要のあるデータです。ただし、もちろん、純粋なOLTP環境が表示されることはめったにありません。ユーザーは大量のデータセットに対してレポートを実行することを好み、データウェアハウスやデータベースのレポートコピーがないため、 >> 本番環境に対してレポートを実行します。これにより、メモリ要件が複雑になります。現在、メモリ内に古いデータが必要な場合もありますが、必要ない場合もあります。ワークロードを理解することが重要です。データベースに対してどのような種類のクエリが実行されていますか？
Standard Editionを使用している場合は、サーバーにサポートされている最大メモリよりも多くのメモリがあることを確認してください。たとえば、SQL Server 2014以降では、Standard Editionでは、（サーバーの最大メモリ設定を介して）バッファプールに割り当てることができるメモリの最大量は128GBです。したがって、サーバーのメモリを増やして（160GBなど）、サーバーの最大メモリを可能な限り高い値の128GBに設定し、OSやその他のSQLServerプロセスで使用できるメモリを確保する必要があります。さらに、SQL Server 2016 SP1 Standard Editionでは、データベースあたり32GBの制限でインメモリOLTPを使用できます。これはサーバーの最大メモリ値を超えているため、この機能を使用する場合は、それに応じてメモリを購入してください。
ストレージ
ストレージのパフォーマンス要件について話すとき、人々がIOPS（1秒あたりの入出力操作）について話すのをよく耳にします。実際、この記事は、ベンチマークとベースライニングに関する私のPluralsightコースを見た視聴者からの質問に触発されました。質問は、「ユーザーあたりのIO数を見積もるために、1秒あたりの読み取りと書き込みのパフォーマンスモニターカウンターをユーザー接続にどのように関連付けるか」でした。 1秒あたりの読み取りと書き込みは入出力操作であるため、このデータはインスタンスレベルでPerfMonを介して利用できます。これは、インスタンスのIOPS要件を定義するために使用するものです。
ただし、読み取りと書き込みを知っている場合はと ユーザー接続の場合、いくつかの計算を実行して、ユーザーごとのIOPSを計算できます。これは、ソリューションを拡張してユーザーを追加することを計画している場合に役立ちます。ソリューションが拡張できることを確認する必要があります。1つのオプションは、Xユーザー数に基づいてユーザーあたりの計算されたIOPSを取得し、Yユーザー数のインスタンスIOPSを推定することです。ここで、この計算で多くの仮定を行います。新しい接続でシステムを使用する方法は現在と同じであると想定しています。最終的にはそうである場合とそうでない場合があり、システムが導入されるまでわかりません。この値（読み取り+書き込み/ユーザー接続=ユーザーあたりの平均IOPS）を理解すると、予想されるユーザー接続に基づいてソリューションのIOPSを見積もる方法がわかります。
次に、この情報をストレージ担当者に渡して、利用可能な構成について話し合います。ディスクに関する情報（ディスクの数、速度、サイズ、RAID構成など）があれば、ディスク構成の最大IOPSを計算できます。 CrystalDiskMarkを使用してドライブのIOスループットをテストできますが、ストレージが決定されていない場合はテストできない可能性があります。ただし、設置したら、このテストを実行して、特定のドライブのIOPSが予想されるワークロードを満たすことができることを確認する必要があります。
IOPSは、ストレージのパフォーマンスを確認する1つの方法にすぎません。このデータは、発生しているIOの量を示していることを理解してください。理想的には、IOPSを知っていて、要件を満たすストレージがある場合は、レイテンシを最小限に抑える必要があります。ただし、遅延はパフォーマンスに影響を与えるものです。存在するレイテンシを判断するには、DiskSpdなどのツールを使用してストレージのベンチマークを行う必要があります。 Glennには、IOパフォーマンスを分析する方法を説明するすばらしい記事があり、次にDiskSpdを使用してレイテンシを理解するためにそれをテストする方法に関する別の記事があります。以前にストレージとパフォーマンスを確認したことがない場合は、両方の記事を確認することを強くお勧めします。
結論
キャパシティプランニングとは、データベースファイルに必要なスペースを知ることだけではありません。ワークロードと、CPU、メモリ、およびディスクリソースの観点から必要なワークロードを理解する必要があります。これを行うには、データが必要です。つまり、キャプチャベースラインが必要です。 SQL Serverコミュニティでの最初のセッションは、2010年12月で、ベースラインのトピックでした。 6年後、私はまだ彼らの重要性について話していて、彼らがこれらの番号を持っていないということを人々からまだ聞いています。インテリジェントで的を絞ったキャパシティプランニングを行う場合は、適切なデータを収集する必要があります。そうでない場合は、推測しているだけです。