Det är oklokt att köra SQL Server med alla annan produkt, inklusive en annan instans av SQL Server. Anledningen till denna rekommendation är karaktären på hur SQL Server använder OS-resurserna. SQL Server körs på en minneshanterings- och processorplaneringsinfrastruktur för användarläge som heter SQLOS . SQL Server är designad för att köras med toppprestanda och antar att det är den enda servern på operativsystemet. Som sådan reserverar SQL OS allt RAM-minne på maskinen för SQL-process och skapar en schemaläggare för varje CPU-kärna och allokerar uppgifter för alla schemaläggare att köra, och använder all CPU den kan få, när den behöver den. Eftersom SQL reserverar allt minne, kommer andra processer som behöver minne att få SQL att se minnestryck , och svaret på minnestryck kommer att kasta sidor från buffertpoolen och kompilerade planer från planens cache. Och eftersom SQL är den enda servern som faktiskt utnyttjar minnet meddelande API (det finns rykten om att nästa Exchange kommer att göra det också), SQL är den enda processen som faktiskt krymper för att ge utrymme åt andra processer (som läckande buggy ASP-pooler). Detta beteende förklaras också i BOL:Dynamisk minneshantering .
Ett liknande mönster händer med CPU-schemaläggning där andra processer stjäl CPU-tid från SQL-schemaläggarna. På avancerade system och på Opteron-maskiner blir det värre eftersom SQL använder NUMA lokalitet till full nytta, men inga andra processer är vanligtvis inte medvetna om NUMA och, så mycket som operativsystemet kan försöka bevara lokaliseringen av allokering, slutar de med att allokera över det fysiska RAM-minnet och minska den totala genomströmningen av systemet som processorer går på tomgång och väntar på sidåtkomst över numa. Det finns andra saker att tänka på, som TLB och L2 miss ökning på grund av att andra processer tar upp CPU-cykler.
Så för att sammanfatta, du kan kör andra servrar med SQL Server, men rekommenderas inte. Om du måste , se till att du isolerar de två servrarna efter bästa förmåga. Använd CPU-affinitetsmasker för båda SQL och IIS/ASP för att isolera de två på separata kärnor, konfigurera SQL för att reservera mindre RAM så att det lämnar ledigt minne för IIS/ASP, konfigurera dina apppooler att återvinnas aggressivt för att förhindra tillväxt av applikationspooler.