Il n'est pas judicieux d'exécuter SQL Server avec any autre produit, y compris une autre instance de SQL Server. La raison de cette recommandation est la nature de la façon dont SQL Server utilise les ressources du système d'exploitation. SQL Server s'exécute sur une infrastructure de gestion de la mémoire et de planification du processeur en mode utilisateur appelée SQLOS . SQL Server est conçu pour fonctionner à des performances optimales et suppose qu'il s'agit du seul serveur sur le système d'exploitation. En tant que tel, le système d'exploitation SQL réserve toute la RAM de la machine pour le processus SQL et crée un planificateur pour chaque cœur de processeur et alloue des tâches à tous les planificateurs à exécuter, en utilisant tout le processeur qu'il peut obtenir, quand il en a besoin. Étant donné que SQL réserve toute la mémoire, les autres processus nécessitant de la mémoire obligeront SQL à voir pression mémoire , et la réponse à la pression de la mémoire expulsera les pages du pool de mémoire tampon et les plans compilés du cache de plan. Et puisque SQL est le seul serveur qui exploite réellement la mémoire notification API (il y a des rumeurs selon lesquelles le prochain Exchange le sera aussi), SQL est le seul processus qui se rétrécit réellement pour donner de la place à d'autres processus (comme les pools ASP bogués qui fuient). Ce comportement est également expliqué dans BOL :Gestion dynamique de la mémoire .
Un schéma similaire se produit avec la planification CPU où d'autres processus volent du temps CPU aux planificateurs SQL. Sur les systèmes haut de gamme et sur les machines Opteron, les choses empirent car SQL utilise NUMA la localité à son avantage, mais aucun autre processus n'est généralement pas au courant de NUMA et, autant que le système d'exploitation peut essayer de préserver la localité des allocations, ils finissent par allouer toute la RAM physique et réduisent le débit global du système comme les processeurs sont inactifs en attente d'un accès à la page frontière inter-numa. Il y a d'autres choses à considérer aussi comme TLB et L2 miss augmentation en raison d'autres processus prenant des cycles CPU.
Donc, pour résumer, vous pouvez exécuter d'autres serveurs avec SQL Server, mais n'est pas recommandé. Si vous devez , puis assurez-vous d'isoler les deux serveurs de votre mieux. Utiliser les masques d'affinité CPU pour les deux SQL et IIS/ASP pour isoler les deux sur des cœurs distincts, configurez SQL pour réserver moins de RAM afin qu'il laisse de la mémoire libre pour IIS/ASP, configurez vos pools d'applications pour qu'ils se recyclent de manière agressive afin d'empêcher la croissance du pool d'applications.
