Het is onverstandig om SQL Server uit te voeren met elke ander product, inclusief een ander exemplaar van SQL Server. De reden voor deze aanbeveling is de aard van de manier waarop SQL Server de OS-bronnen gebruikt. SQL Server draait op een gebruikersmodus geheugenbeheer en processorplanningsinfrastructuur genaamd SQLOS . SQL Server is ontworpen om topprestaties te leveren en gaat ervan uit dat dit de enige server op het besturingssysteem is. Als zodanig reserveert het SQL-besturingssysteem alle RAM op de machine voor het SQL-proces en creëert het een planner voor elke CPU-kern en wijst het taken toe aan alle planners om uit te voeren, gebruikmakend van alle CPU die het kan krijgen, wanneer het het nodig heeft. Omdat SQL al het geheugen reserveert, zorgen andere processen die geheugen nodig hebben ervoor dat SQL geheugendruk , en de reactie op geheugendruk zal pagina's uit de bufferpool en gecompileerde plannen uit de plancache verwijderen. En aangezien SQL de enige server is die daadwerkelijk gebruik maakt van het geheugen melding API (er gaan geruchten dat de volgende Exchange dat ook zal doen), SQL is het enige proces dat daadwerkelijk krimpt om ruimte te geven aan andere processen (zoals lekkende ASP-pools met fouten). Dit gedrag wordt ook uitgelegd in BOL:Dynamisch geheugenbeheer .
Een soortgelijk patroon doet zich voor bij CPU-planning, waarbij andere processen CPU-tijd stelen van de SQL-planners. Op geavanceerde systemen en op Opteron-machines wordt het erger omdat SQL NUMA gebruikt plaats ten volle te benutten, maar geen enkel ander proces is zich gewoonlijk niet bewust van NUMA en, hoezeer het besturingssysteem ook kan proberen de plaats van toewijzingen te behouden, ze zullen uiteindelijk het hele fysieke RAM-geheugen toewijzen en de algehele doorvoer van het systeem als de CPU's verminderen wachten op cross-numa grenspaginatoegang. Er zijn ook andere dingen om te overwegen, zoals TLB en L2 missen toename doordat andere processen CPU-cycli in beslag nemen.
Kortom, u kunt andere servers met SQL Server uitvoeren, maar dit wordt niet aanbevolen. Als je moet en zorg er vervolgens voor dat u de twee servers zo goed mogelijk isoleert. Gebruik CPU-affiniteitsmaskers voor beide SQL en IIS/ASP om de twee op afzonderlijke cores te isoleren, SQL configureren om minder RAM te reserveren zodat er vrij geheugen overblijft voor IIS/ASP, uw app-pools configureren om agressief te recyclen om groei van de toepassingspool te voorkomen.