Es ist unklug, SQL Server mit any auszuführen anderes Produkt, einschließlich einer anderen Instanz von SQL Server. Der Grund für diese Empfehlung liegt in der Art und Weise, wie SQL Server die Betriebssystemressourcen verwendet. SQL Server wird auf einer Speicherverwaltungs- und Prozessorplanungsinfrastruktur im Benutzermodus namens SQLOS . SQL Server ist für die Ausführung mit Spitzenleistung ausgelegt und geht davon aus, dass dies der einzige Server im Betriebssystem ist. Als solches reserviert das SQL-Betriebssystem den gesamten Arbeitsspeicher auf dem Computer für den SQL-Prozess und erstellt einen Planer für jeden CPU-Kern und weist Aufgaben für alle auszuführenden Planer zu, wobei er die gesamte CPU nutzt, die er bekommen kann, wenn er sie braucht. Da SQL den gesamten Speicher reserviert, bewirken andere Prozesse, die Speicher benötigen, dass SQL Speicherdruck , und die Antwort auf Speicherüberlastung entfernt Seiten aus dem Pufferpool und kompilierte Pläne aus dem Plancache. Und da SQL der einzige Server ist, der tatsächlich den Speicher nutzt Benachrichtigung API (es gibt Gerüchte, dass die nächste Exchange dies auch tun wird), ist SQL der einzige Prozess, der tatsächlich schrumpft, um Platz für andere Prozesse zu schaffen (wie undichte fehlerhafte ASP-Pools). Dieses Verhalten wird auch in BOL erklärt:Dynamic Memory Management .
Ein ähnliches Muster tritt bei der CPU-Planung auf, bei der andere Prozesse die CPU-Zeit von den SQL-Schedulern stehlen. Auf High-End-Systemen und auf Opteron-Rechnern wird es noch schlimmer, weil SQL NUMA verwendet Lokalität voll ausnutzen, aber keine anderen Prozesse kennen NUMA normalerweise nicht, und so sehr das Betriebssystem versuchen kann, die Lokalität von Zuweisungen beizubehalten, weisen sie am Ende den gesamten physischen RAM zu und reduzieren den Gesamtdurchsatz des Systems wie die CPUs warten im Leerlauf auf den Seitenzugriff über die numa-Grenze hinweg. Es gibt auch andere Dinge zu beachten, wie TLB und L2-Fehltreffer nehmen zu, weil andere Prozesse CPU-Zyklen in Anspruch nehmen.
Zusammenfassend lässt sich sagen, dass Sie können Führen Sie andere Server mit SQL Server aus, wird jedoch nicht empfohlen. Wenn Sie müssen , stellen Sie dann sicher, dass Sie die beiden Server so gut wie möglich isolieren. Verwenden Sie CPU-Affinitätsmasken für beide SQL und IIS/ASP, um die beiden auf separaten Kernen zu isolieren, konfigurieren Sie SQL so, dass weniger RAM reserviert wird, sodass freier Speicher für IIS/ASP bleibt, konfigurieren Sie Ihre Anwendungspools so, dass sie aggressiv recycelt werden, um ein Wachstum des Anwendungspools zu verhindern.
