Taille de fichier d'échange recommandée pour SQL 2008R2 sous Windows 2008R2

Cet article Microsoft - Comment déterminer la taille de fichier d' échange appropriée pour les versions 64 bits de Windows Server 2008 et ou Windows 2008 R2 fournit des conseils pour calculer la taille du fichier d'échange pour Windows 2008 64 bits et Windows 2008R2 64 bits. Cela fonctionne sans aucun doute bien pour les serveurs à usage général. Je me demande quelles sont les instructions pour SQL Server 2008R2 fonctionnant sur Windows 2008 / R2 64 bits?

Je suppose que nous voulons que le moins de données en mémoire atteigne le fichier d'échange, sinon SQL pourrait frapper le disque deux fois pour les données. SQL Server autorise-t-il même les données en mémoire à atteindre le fichier d'échange? J'ai cherché dans la documentation en ligne de SQL Server 2008 R2 pour obtenir des conseils, mais je n'ai encore trouvé aucune mention de l'utilisation du fichier d'échange.

Voici un scénario d'utilisation potentiel: étant donné un serveur physique avec 64 Go de RAM, un fichier d'échange est-il nécessaire pour l'ensemble des 64 Go de RAM? Devrions-nous le préparer pour 96 Go de fichier d'échange? Cela semble un peu excessif pour un seul fichier. Je sais que la sagesse conventionnelle veut que Windows associe le fichier d'échange à la mémoire dans le but de faciliter l'échange d'applications sur la RAM, mais est-ce vrai? Un fichier d'échange de moins de 64 Go entravera-t-il les performances ici?

Il n'y a pas de paramètres spéciaux pour SQL Server qui utilise uniquement la mémoire physique normalement

Faites ce que MS dit pour Windows et c'est tout

Oh, et achetez quand même plus de RAM pendant que nous sommes un sujet ... ;-)

Regardez lock pages in memory. De cette façon, vous pouvez préférer que votre compte de service SQL utilise la RAM disponible plutôt que la pagination sur le disque. Pour en savoir plus sur les pages de verrouillage en mémoire, consultez ce lien . Un extrait suit:

L'option Verrouiller les pages en mémoire de la stratégie Windows est désactivée par défaut. Ce privilège doit être activé pour configurer les extensions de fenêtrage d'adresses (AWE). Cette stratégie détermine quels comptes peuvent utiliser un processus pour conserver les données dans la mémoire physique, empêchant le système de paginer les données vers la mémoire virtuelle sur le disque. Sur les systèmes d'exploitation 32 bits, la définition de ce privilège lorsque vous n'utilisez pas AWE peut considérablement réduire les performances du système. Le verrouillage des pages en mémoire n'est pas requis sur les systèmes d'exploitation 64 bits.

Veuillez tester cette fonctionnalité avant de l'utiliser sur vos systèmes.

Oui, pour 64 Go de RAM, vous avez besoin d'au moins 64 Go de fichier d'échange (96 Go recommandés). Pas à cause d'un échange potentiel, mais à cause de la conception du gestionnaire de mémoire Windows. J'ai déjà écrit sur ce problème dans la taille du fichier d'échange système sur les machines avec une grande RAM :

Lorsqu'un processus demande de la MEM_COMMITmémoire via VirtualAlloc/ VirtualAllocEx, la taille demandée doit être réservée dans le fichier d'échange. Cela était vrai dans le premier système Win NT, et c'est toujours vrai aujourd'hui, voir Gestion de la mémoire virtuelle dans Win32 :

Lorsque la mémoire est engagée, des pages physiques de mémoire sont allouées et de l'espace est réservé dans un fichier d'échange.

L'alternative serait quelque chose comme oom_killer .

Suivez donc la recommandation, parfois les choses sont un peu plus complexes qu'elles ne le paraissent. Et je n'ai même pas touché aux complications apportées par AWE et au privilège de verrouillage des pages ...