Nierozsądne jest uruchamianie SQL Server z dowolnym inny produkt, w tym inna instancja SQL Server. Powodem tego zalecenia jest sposób, w jaki SQL Server wykorzystuje zasoby systemu operacyjnego. SQL Server działa w infrastrukturze zarządzania pamięcią trybu użytkownika i planowania procesora o nazwie SQLOS . SQL Server został zaprojektowany do działania z najwyższą wydajnością i zakłada, że jest to jedyny serwer w systemie operacyjnym. W związku z tym system operacyjny SQL rezerwuje całą pamięć RAM na komputerze dla procesu SQL i tworzy harmonogram dla każdego rdzenia procesora i przydziela zadania wszystkim harmonogramom, wykorzystując cały procesor, jaki może uzyskać, kiedy tego potrzebuje. Ponieważ SQL rezerwuje całą pamięć, inne procesy, które potrzebują pamięci, spowodują, że SQL zobaczy ciśnienie pamięci , a odpowiedź na obciążenie pamięci spowoduje wykluczenie stron z puli buforów i skompilowanych planów z pamięci podręcznej planów. A ponieważ SQL jest jedynym serwerem, który faktycznie wykorzystuje pamięć powiadomienie API (krążą pogłoski, że następna Exchange też będzie), SQL jest jedynym procesem, który faktycznie kurczy się, aby dać miejsce innym procesom (takim jak nieszczelne pule ASP). To zachowanie jest również wyjaśnione w BOL:Dynamiczne zarządzanie pamięcią .
Podobny wzorzec ma miejsce w przypadku planowania procesora, gdzie inne procesy kradną czas procesora z harmonogramów SQL. W zaawansowanych systemach i na maszynach Opteron sytuacja się pogarsza, ponieważ SQL używa NUMA lokalność do pełnej korzyści, ale żadne inne procesy zwykle nie są świadome NUMA i chociaż system operacyjny może próbować zachować lokalność alokacji, w końcu przydzielają całą fizyczną pamięć RAM i zmniejszają ogólną przepustowość systemu, podobnie jak procesory oczekują na dostęp do strony z przekrojowymi granicami liczb. Są też inne rzeczy do rozważenia, takie jak TLB i wzrost braku L2 z powodu innych procesów zajmujących cykle procesora.
Podsumowując, możesz uruchamiać inne serwery z SQL Server, ale nie jest to zalecane. Jeśli musisz , a następnie upewnij się, że izolujesz dwa serwery, jak najlepiej potrafisz. Użyj masek koligacji procesora dla obu SQL i IIS/ASP, aby izolować je na osobnych rdzeniach, skonfiguruj SQL, aby rezerwować mniej pamięci RAM, aby pozostawić wolną pamięć dla IIS/ASP, skonfiguruj pule aplikacji tak, aby agresywnie je odtwarzały, aby zapobiec wzrostowi puli aplikacji.
