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?

— Kev
source

Réponses:

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 ... ;-)

— gbn
source

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.

— StanleyJohns
source

«Verrouiller les pages en mémoire» pourrait peut-être mieux être décrit comme une sauvegarde, pour empêcher la mémoire SQL d'être paginée par le système d'exploitation. support.microsoft.com/kb/918483

— Mark Storey-Smith

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 ...

— Remus Rusanu
source

Très intéressant ... Comment ça marche alors lorsque vous définissez un fichier d'échange plus petit que la RAM de la machine? Si en effet nous devons réserver l'espace dans le fichier d'échange pour chaque allocation de mémoire, nous ne pourrions pas utiliser plus de mémoire que la taille du fichier d'échange? Je ne suis pas sûr que cela fonctionne dans la pratique.

— shlomoid

C'est exactement ainsi que cela fonctionne dans la pratique. Une région VA engagée doit être soutenue par une réelle réserve de swap. Une région VA réservée ne doit pas l'être, mais SQL Server ne demande pratiquement jamais de réservation non validée.

— Remus Rusanu

Je ne pense pas que ce soit correct. Ma compréhension de diverses sources telles que les livres Windows Internals est que l'espace d'adressage virtuel engagé doit être soutenu par quelque chose de physique , soit un fichier d'échange ou une RAM. Donc, si vous essayez de valider la mémoire virtuelle> ([La mémoire physique que Windows voit] + [Taille du fichier d'échange]), vous obtiendrez le tristement célèbre message d'erreur "Votre système manque de mémoire virtuelle". Mark Russinovich parle à ce sujet dans la section intitulée « mémoire engagée » ici .

— James L

Je pense que vous pouvez vous confirmer que les régions VA engagées ne doivent pas être soutenues par des réservations d'échange simplement en démarrant un système sans fichier d'échange et en confirmant que Windows démarre, et donc il doit y avoir plus de 0 octet de VAS engagé.

— James L

Ce message est erroné - il est parfaitement possible de s'exécuter sans fichier d'échange si vous avez plus de mémoire que vos exigences de validation max. Cela signifie cependant que vous ne pouvez pas écrire de vidages sur incident.

— Steve365