私は、同じマシンにSQL ServerとIISをインストールするのは賢明ではないことを読んだことがありますが、それについての証拠はありませんでした。誰かがこれを試したことがありますか？あれば、結果は何ですか？どの時点でそれらを分ける必要がありますか？チューニングは必要ですか？私は特にIIS7とSQL Server 2008に心配しています。IISとSQL Serverを同じマシンでホストできるのはいつですか？
誰かが2台のマシンに行くのが理にかなっていることを示す数字を提供できるなら、それが最も役立ちます。
他の製品（SQL Serverの別のインスタンスを含む）でSQL Serverを実行することは賢明ではありません。この推奨の理由は、SQL ServerがOSリソースをどのように使用するかという性質にあります。 SQL Serverは、ユーザーモードのメモリ管理とプロセッサスケジューリングインフラストラクチャ（SQLOS）で動作します。 SQL Serverは最高のパフォーマンスで動作するように設計されており、それがOS上の唯一のサーバーだと想定しています。このように、SQLはSQL処理のためにマシン上のすべてのRAMを予約し、各CPUコア用のスケジューラを作成し、必要なときにすべてのCPUを利用してすべてのスケジューラを実行するタスクを割り当てます。 SQLはすべてのメモリーを予約するため、メモリーを必要とする他のプロセスではSQLにmemory pressureが表示され、メモリー・プレッシングの応答によって、バッファー・プールおよびコンパイル済みプランからのページがプラン・キャッシュから除去されます。そして、SQLは実際にmemory notification APIを活用している唯一のサーバー（次のExchangeもそうであるという噂がある）であるため、SQLは、漏れたバグのASPプールのような他のプロセスに余裕を与えるために実際に縮小される唯一のプロセスです。この動作は、BOL：Dynamic Memory Managementでも説明されています。
他のプロセスがSQLスケジューラからCPU時間を奪うCPUスケジューリングでも同様のパターンが発生します。ハイエンドシステムやOpteronマシンでは、SQLはNUMAローカリティをフル活用するために悪化しますが、他のプロセスは通常NUMAを意識していませんし、OSが割り当ての局所性を維持しようとする限り、物理RAM上で実行され、CPUがクロスnuma境界ページアクセスを待ってアイドル状態になると、システムの全体的なスループットが低下します。他にもTLBやL2ミスがCPUサイクルを浪費する他のプロセスのために増加することも考えられます。
合計すると、は、SQL Serverで他のサーバーを実行できますが、お勧めしません。 がである必要がある場合は、2つのサーバーを最適な状態に分離してください。 のCPUアフィニティマスクを使用する SQLとIIS/ASPを分離してコアを分離し、RAMを少なくしてIIS/ASPの空きメモリを残すようにSQLを構成し、アプリケーションプールを積極的にリサイクルしてアプリケーションプールの成長を防ぎます。 。
はい、可能です。
実稼働環境ではいい考えですが、
実行しようとしている問題は、大量のSQL ServerデータベースがディスクI/Oを大量に使用している可能性が高く、メモリフットプリントが大きいことです。その組み合わせによってマシンが縛られ、ページを提供しようとするときにIISでパフォーマンスが低下します。
はい、可能であり、多くあります。
セキュリティやパフォーマンスの問題となる傾向があります。
攻撃の対象となるのは、両方の攻撃対象が増えているためです。おそらくあなたのための問題ではありません。
サーバーがWeb要求とDB要求を処理しているため、パフォーマンスが疑問視されています。もう一度、おそらくあなたの場合の問題ではありません。
生産対テスト....
多くは、生産テスト環境でスッキリないかもしれませんが....再び
、あなたのチームの呼び出しを。私は、テスト環境とプロダクション環境ができるだけ似ているのが好きですが、それは私の好みです。
私はhanselminutesエピソード134および/または135が、SOが1台のサーバーで実行されていることを明らかにしました。間違いなく、スコットはアイデアに少し驚いていた。 :) – klabranche
特定の状況では賢明ではありません...他の人には全く賢明です。
マシンが十分に活用されていないため、負荷が重くない場合は、ネットワーク経由で何も転送する必要がないため、同じマシンにデータベースをインストールする利点があります。
一方、IISまたはデータベースの一方または両方に負荷がかかると、それらはおそらく干渉を開始し、専用ハードウェアのパフォーマンスの向上はおそらくオーバーヘッドの損失を上回りますネットワーク。
することもできます。たとえば、ユーザーベースが大きい場合や、DBに対して多量のクエリが実行されている場合は、パフォーマンスの問題が発生します。私は、1and1でホストされているいくつかのサイトで、IISとSQL Server（Express！）を何千ものユーザー（数百人の同時ユーザー）と、不十分に作成されたストアドプロシージャを介してアクセスされ、ユーザーエクスペリエンスは確かに耐えられました。それはすべてあなたがサーバーに当たることを計画することがどれほど難しいかということになります。
メンテナンスの問題を忘れないでください。リブートしたり、パッチを当てたりすることはできません。それらが2つのボックスにある場合は、SQLボックスを維持している場合、Webサーバーからの応答よりも優れたエクスペリエンスをユーザに与えることができます。
リストには載っていませんが、注意する必要があります。
@Remus Rusanu - 自分自身を含めて多くのあなたの答えが好きです。良い技術情報！ :)私は答えがしばしば状況に依存していると思う。シンプルさとコストのために単一のサーバー技術を使用しました。私たちの状況にあるリソースは分離を必要としませんでした。それらの要件が変更されたときに変更されましたが、それが起こるには約8年かかりました。私は多くの中小企業が同じ状況で自分自身を見つけるかもしれないと思います。思考？ – klabranche
@klabranche：私が提供した技術情報は、メモリーとI/OとCPUがSQLとIIS/ASPの間でできるだけ分割されるように、混在サーバーを構成するのに役立ちます。長期的には、IIS/ASPは容易にスケールアウトできますが、SQLは簡単にスケールアップできます。したがって、SQL/ASPを農場や安価なコモディティハードウェアの「庭園」でIIS/ASPを移動するのが自然な傾向ですが、SQLは、その組織が自由に利用できる最大のマシンにとどまっています。 –
@Remus Rusanu - 私は同意します。中小規模の店舗/アプリケーションでは、単一サーバの状況が必ずしも悪い方法ではないことに同意しますか？ – klabranche