anyを使用してSQLServerを実行することは賢明ではありません。 SQLServerの別のインスタンスを含む他の製品。この推奨の理由は、SQLServerがOSリソースを使用する方法の性質です。 SQL Serverは、 SQLOS
。 SQL Serverは、最高のパフォーマンスで実行するように設計されており、OS上の唯一のサーバーであると想定しています。そのため、SQL OSはマシン上のすべてのRAMをSQLプロセス用に予約し、CPUコアごとにスケジューラを作成し、必要なときに取得できるすべてのCPUを利用して、実行するすべてのスケジューラにタスクを割り当てます。 SQLはすべてのメモリを予約するため、メモリを必要とする他のプロセスにより、SQLはメモリプレッシャー
、およびメモリプレッシャーへの応答により、ページがバッファプールから削除され、コンパイルされたプランがプランキャッシュから削除されます。また、SQLは、メモリを実際に利用する唯一のサーバーであるため、通知
API（次のExchangeもそうなるという噂があります）、SQLは、他のプロセス（リークのあるバグのあるASPプールなど）にスペースを与えるために実際に縮小する唯一のプロセスです。この動作は、BOLでも説明されています：
同様のパターンは、他のプロセスがSQLスケジューラからCPU時間を盗むCPUスケジューリングでも発生します。ハイエンドシステムおよびOpteronマシンでは、SQLが NUMA を使用するため、状況はさらに悪化します。 ローカリティを最大限に活用しますが、他のプロセスは通常NUMAを認識せず、OSが割り当てのローカリティを維持しようとする限り、物理RAM全体に割り当てられ、CPUとしてのシステムの全体的なスループットが低下します。クロスnuma境界ページアクセスを待機しているときにアイドリングしています。 TLB のように考慮すべき点は他にもあります。 他のプロセスがCPUサイクルを消費するため、L2ミスが増加します。
つまり、要約すると、 SQL Serverで他のサーバーを実行しますが、お勧めしません。 必須の場合 次に、2台のサーバーを最大限に分離するようにしてください。 両方にCPUアフィニティマスクを使用する SQLとIIS/ASPは、2つを別々のコアに分離し、IIS / ASP用に空きメモリを残すようにRAMを予約するようにSQLを構成し、アプリケーションプールの増加を防ぐために積極的にリサイクルするようにアプリプールを構成します。