Non è saggio eseguire SQL Server con qualsiasi altro prodotto, inclusa un'altra istanza di SQL Server. Il motivo di questa raccomandazione è la natura del modo in cui SQL Server utilizza le risorse del sistema operativo. SQL Server viene eseguito su un'infrastruttura di pianificazione del processore e di gestione della memoria in modalità utente denominata SQLOS . SQL Server è progettato per funzionare al massimo delle prestazioni e presuppone che sia l'unico server nel sistema operativo. In quanto tale, il sistema operativo SQL riserva tutta la RAM sulla macchina per il processo SQL e crea uno scheduler per ciascun core della CPU e alloca le attività per l'esecuzione di tutti gli scheduler, utilizzando tutta la CPU che può ottenere, quando necessario. Poiché SQL riserva tutta la memoria, altri processi che richiedono memoria faranno sì che SQL visualizzi pressione di memoria e la risposta alla pressione della memoria eliminerà le pagine dal pool di buffer e i piani compilati dalla cache dei piani. E poiché SQL è l'unico server che sfrutta effettivamente la memoria notifica API (ci sono voci che lo farà anche il prossimo Exchange), SQL è l'unico processo che in realtà si riduce per dare spazio ad altri processi (come pool ASP che perdono bug). Questo comportamento è spiegato anche in BOL:Gestione dinamica della memoria .
Un modello simile si verifica con la pianificazione della CPU in cui altri processi rubano il tempo della CPU dagli scheduler SQL. Sui sistemi di fascia alta e su macchine Opteron le cose peggiorano perché SQL utilizza NUMA località a pieno vantaggio, ma nessun altro processo di solito non è a conoscenza di NUMA e, per quanto il sistema operativo possa cercare di preservare la località delle allocazioni, finiscono per allocare tutta la RAM fisica e ridurre il throughput complessivo del sistema come le CPU sono inattivi in attesa dell'accesso alla pagina limite tra i numeri. Ci sono anche altre cose da considerare come TLB e L2 mancato aumento a causa di altri processi che richiedono cicli della CPU.
Quindi, per riassumere, puoi eseguire altri server con SQL Server, ma non è consigliato. Se devi , quindi assicurati di isolare i due server al meglio. Usa le maschere di affinità della CPU per entrambi SQL e IIS/ASP per isolare i due su core separati, configurare SQL per riservare meno RAM in modo che lasci memoria libera per IIS/ASP, configurare i pool di app per riciclare in modo aggressivo per prevenire la crescita del pool di applicazioni.
