より多くの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、毎月250 MBの割合で増加しています。現在、Webサーバー（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にSSDを1つだけ）、トランザクションログとtempdbを4xHDD RAID10に移動しました。構成。 SSDでtempdbを使用してテストしたところ、すばらしい結果が得られました（実際には、クエリが15倍以上高速で非常に良い結果が得られ、一部のレポートでは過去数分ではなく数秒かかる）。後でtempdbをディスクRAID10に移動したため、 SSDの書き込み摩耗の集中的な懸念の。
したがって、基本的には、最も長いクエリの一部について、応答時間が10〜15倍速くなることがわかりました。 SSDは、RAMにデータを読み込むのに最適です。SQLServerは、RAMに要求されるまでデータを読み込まないため、最初にデータをロードする必要があるためです。 RAM CPUによって処理される（後で、L1、L2、L3キャッシュで）ため、SSDはその初期待機時間を大幅に削減し、スワップ時間を短縮します。 。RAM=をクリアして新しいデータをロードする。特に、データベースがRAMに収まらないほど大きい場合。
全体として、サーバーを稼働させてすべてのサーバーをこの構成に切り替える前に摩耗レベルの情報を収集できるように、一種の遅い移行プロセスで数か月間このように実行しており、非常に満足しています。そして、これは単なるSQL Server Expressです。 ：D-SSDが一定のIOPSを提供できることを確認してください。これは大きな違いを生むもう1つの理由です（ググってみてください）。そのため、私はIntel DC（DataCenter）シリーズSSDを選択しました。
最初の部分でおそらく探している答えはやや違いますが、それをクラウドにプッシュすることを検討しましたか？ AWSでは、上記のニーズのほとんどを提供し、ハードウェアを扱うことなく購買力を拡大することができます。
第二部-ハードウェアは本当にタスクに依存します。カスタムCLR統合を実行できる場合は、CPUの数を増やす傾向があります。それは、問題に対する真の並列ソリューションを最適化できるためです。ほとんどの場合、ベースのソリューションを設定した方がよい場合は、RAMであり、ハードドライブの速度が最大のボトルネックであり、2番目があなたのケースであると思われます（上記のSSDのアイデアの場合）参考になります）
サーバーからの実際の統計情報がない場合は、書き込みを減らすためのいくつかのキャッシュソリューションを調べて（書き込みで何らかのログを記録している場合や、履歴が必要な場合を除き）、ハードドライブに多くのお金を投入することをお勧めしますCPUよりも。 SQLサーバーは、クエリの並列処理に優れています（書き込み用に作成されている場合）が、書き込みが多すぎる場合は、ハードドライブが実際のボトルネックになります。