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 64 bits Windows 2008 et Windows 2008R2. 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 sous 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 des données. SQL Server autorise-t-il même les données en mémoire à atteindre le fichier d'échange ? J'ai cherché 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 potentielle: É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 plus RAM de toute façon pendant que nous sommes un sujet ... ;-)
Examinez lock pages in memory. De cette façon, vous pouvez donner la préférence à votre compte de service SQL pour utiliser la RAM plutôt que la pagination sur le disque. Pour en savoir plus sur les pages de verrouillage en mémoire, vérifiez ceci 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 RAM vous avez besoin d'au moins fichier d'échange de 64 Go (96 Go recommandé). Pas à cause d'un échange potentiel, mais à cause de la conception du gestionnaire de mémoire Windows. J'ai déjà parlé de ce problème dans taille du fichier d'échange système sur les machines avec une grande RAM :
Lorsqu'un processus demande
MEM_COMMITmémoire viaVirtualAlloc/VirtualAllocEx, la taille demandée doit être réservée dans le fichier d'échange. C'é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 ...