より多くのCPUコアとより高速なディスク

私は小さな会社の一員なので、いつものようにさまざまな役割を担当しています。最新のものは、.NET Webアプリ専用のSQL Serverボックスを調達しています。32 GBのRAMを備えたデュアルXeon E5-2620（6コア）2.00 GHz CPU構成（合計12コア）で引用されています。これにより、ディスクアレイの予算が制限され、基本的にRAID 1構成の2つの2.5インチSAS 300 GBドライブ（15k RPM）で構成されます。

ディスクのセットアップがSQL Serverにとって最適ではないことを知っているので、データベース、ログファイル、およびtempdbを独自のドライブに配置できるように、RAID 10をプッシュしたいと考えています。これを予算と両立させるには、CPUコアの数を減らすことを検討する必要がありますか？それとも、コアを保持し、使用するドライブを少なくして、おそらくデュアルRAID 1セットアップで4台を使用することで、より良い銀行を獲得できますか？

追加の統計情報は次のとおりです

• SQL Serverデータベースは、おそらく80％対20％の多数の読み取りから書き込みに傾いています。現在のDBサイズは現在約10 GB、 26 GBで、1か月あたり250 MBの割合で増加しています。

• 現在、Webサーバー（RAID 1の12 GB Ram、2 x 10k 300GB SASドライブ）と共有されているシングルクアッドコアXeonボックスでSQL Server 2008 R2 Standardを実行し、SQL Server 2012 Standardへの移行を検討しています。

• データベースは約100〜150人の同時ユーザーにサービスを提供し、バックグラウンドスケジューリングタスクがスローされます。これを読んで、12コアは深刻すぎると思います！

SQL Azure DBにリンクされたAzureクラウドサービス（2つの小さなインスタンス）にアプリケーション全体をデプロイしました。テスト時のパフォーマンスは合理的でしたが（ほとんどゼロの負荷）、予測不可能だったため、本番環境で使用する勇気を失いました。スケールアウトのアプローチではうまくいくかもしれませんが、たった10 GBのデータベースを使用すれば、今すぐスケールアップしてお金を節約できます。

最初はライセンスコストを見落としていましたが、SQL Server 2012のライセンスがコアの数に基づいていることに気付きませんでした。SQL Server 2012 StandardライセンスのBizSpark MSDNサブスクリプションを持っているので、これがすぐに利用できるコアの数について調べる必要があります。

謙虚ですが、共有する価値があると思う経験から言えば、SQLデータベース（ここではSybaseとSQLサーバー）の主なボトルネックはストレージです。

しかし、間違った仮定をする前に誰かが最初にセットアップのベンチマークをとることは公平だと思います。私の場合、CPUの使用率はCPUのアップグレードをすぐに正当化するほど高くなりませんでした。代わりに、単一ドライブからRAID 1にアップグレードし、次にRAID 10 + 8 GBから16 GBのRAMにアップグレードしました。

これらすべてのRAIDアップグレードは、以前の待機時間を2倍から6分の1に短縮するのに役立ちました。SSDへのアップグレードはさらに改善されると思います。考えてみると、すべてを（理論上の）帯域幅に減らすことができます。[（RAM速度+ RAMサイズ+メモリコントローラー）CPUへのリンク]コンボには、データを常にキャッシュする必要がある場合に読み取り操作で最も重要な要因となる帯域幅制限があり、特定の（RAID）ストレージには帯域幅制限があります（キャッシュが失われたときに読み取りに影響し、フラッシュ時に書き込みが行われるか、多くのクライアントが大量のデータを組み合わせて書き込みます。

これらのすべての制限を可能な限り正規化し（リソースを無駄にしないように近づけて）、必要に応じてそれらを引き上げます（必要な場合にアップグレードし、必要な場合のみ、システムが不要になった場合にリソースが無駄にならないようにします）。他のボトルネックが邪魔になっているため、それらを使用できるようにします）。最終的に、最悪のボトルネックは、特定の構成で最もパフォーマンスの低い（帯域幅が最小の）サーバーサブシステムになります。

アップグレードの過程で、データベースファイルとデータベースログファイル用に別々のRAID構成を作成したことも追加できます。その理由は、データベースログファイルは書き込みが集中する傾向があるためです。ログファイルは、クラッシュからデータベースを回復するために使用され、データがデータベースファイルに書き込まれる前にトランザクションがコミットされるとすぐに常に書き込まれます。

ログファイルは一部のデータベースレプリケーションサーバーでも使用されますが、ほとんどのレプリケーションは即座にではなく頻繁に行われるため、読み取りパフォーマンスへの影響は最小限です。少なくとも私はそう思う。このアップグレードを行っている最中に最小限のベンチマークを行ったので、CPUのアップグレードを検討する前に、さまざまな構成を最初にベンチマークし、ストレージ、RAM、ネットワークリンクを最初にアップグレードすることをお勧めします。

5台以上のサーバーでより広範なアップグレードを行った後、私は自分の経験を共有するために戻ってきました。最初にストレージをアップグレードし、次にRAMを、次にCPUをアップグレードすることを引き続き推奨します。理由は、ストレージ、RAM、CPU間のシステムの帯域幅の差が、低いものから高いものです。そこで、私は多数のサーバーをRAID10およびデュアルRAID1からSSDにアップグレードしました。

コストを考慮して（アップグレードするサーバーがさらに20台あります）、データベースデータとオブジェクトファイルをSSD（はい、RAID0に1つのSSDのみ）に移動し、トランザクションログとtempdbを4xHDD RAID10に移動します構成。SSDのtempdbでも優れた結果をテストしました（実際には、15倍以上のクエリで非常に良い結果が得られ、過去に数分ではなく数秒かかるレポートが生成されました）が、後でtempdbをディスクRAID10に移動しましたSSDに対する集中的な書き込み摩耗の懸念。

そのため、今では基本的に、いくつかの最も長いクエリごとに応答時間が10〜15倍速くなっています。SSDは、データをRAMに高速で読み込むのに最適です。これは、SQL Serverが要求され、もちろんCPUで処理するためにデータをRAMに読み込む必要があるまでRAMにデータを持ち込まないためです（後でL1、L2、L3キャッシュで） 、SSDはその初期待機時間を大幅に削減するのに役立ちます。また、SSDはスワップ時間の削減にも役立ちます。特に、データベースがRAMに収まらないほど大きい場合は、RAMをクリアして新しいデータをロードします。

全体として、私たちは非常に満足しており、サーバーを実行できるように数か月間、ゆっくりと移行するようなプロセスでそのように実行しているため、すべてのサーバーをこの構成に切り替える前に摩耗レベルの情報を収集できます。そして、これは単なるSQL Server Expressです！：D-SSDが一定のIOPSを提供できることを確認してください。これは大きな違いを生むもう1つのことです（グーグルで検索してください）。それが、Intel DC（DataCenter）シリーズSSDを選んだ理由です。

最初の部分でおそらく探している答えではありませんが、クラウドにプッシュすることを検討しましたか？AWSを使用すると、上記のほとんどのニーズに対応でき、ハードウェアを扱うことなく購買力を高めることができます。

第二部-ハードウェアは本当にタスクに依存します。カスタムCLR統合を実行できる場合は、問題に対する真の並列ソリューション用に最適化できるため、より多くのCPUに傾く傾向があります。ただし、ほとんどの場合、セットベースのソリューションを使用した方がよい場合、RAMとハードドライブの速度が最大のボトルネックであり、2番目のケースはあなたの場合のようです。（上記のSSDのアイデアが役立つ場合）

サーバーからの実際の統計情報がなければ、書き込みを減らすためのキャッシュソリューション（書き込みで何らかのログを記録している場合や、履歴が必要な場合を除く）を見て、ハードドライブに多くのお金をかけることをお勧めしますCPUよりも。SQLサーバーは、クエリを並行して実行するのが得意です（クエリが記述されている場合）が、書き込みが多すぎる場合は、ハードドライブが本当のボトルネックになります。