Taille de fichier d'échange Windows O/S appropriée pour SQL Server

Question

Est-ce que quelqu'un connaît une bonne règle générale pour la taille de fichier d'échange appropriée pour un serveur Windows 2003 exécutant SQL Server ?

Answer 1

Quelle que soit la taille de la RAM, vous avez toujours besoin d'un fichier d'échange représentant au moins 1,5 fois la quantité de RAM physique.Cela est vrai même si vous disposez d'une machine de 1 To de RAM, vous aurez besoin de 1,5 To de fichier d'échange sur le disque (cela semble fou, mais c'est vrai).

Lorsqu'un processus demande de la mémoire MEM_COMMIT via VirtualAlloc/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 encore vrai aujourd'hui, voir Gestion de la mémoire virtuelle dans Win32:

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

Sauf dans certains cas extrêmes, SQL Server demandera toujours les pages MEM_COMMIT.Et étant donné que SQL utilise un Gestion dynamique de la mémoire politique qui réserve dès le départ autant de pool tampon que possible (réserves et commet en termes de VAS), SQL Server demandera au démarrage une énorme réservation d'espace dans le fichier d'échange.Si le fichier d'échange n'est pas correctement dimensionné, les erreurs 801/802 commenceront à apparaître dans le fichier et les opérations ERRORLOG de SQL.

Cela provoque toujours une certaine confusion, car les administrateurs supposent à tort qu'une grande RAM élimine le besoin d'un fichier d'échange.En réalité, au contraire, une grande RAM augmente le besoin de fichier d'échange, simplement à cause du fonctionnement interne du gestionnaire de mémoire de Windows NT.Nous espérons que le fichier d'échange réservé n'est jamais utilisé.

Answer 2

Avec tout le respect que je dois à Remus (que je respecte énormément), je suis fortement en désaccord.Si votre fichier d'échange est suffisamment volumineux pour prendre en charge un vidage complet, il effectuera un vidage complet à chaque fois.Si vous disposez d’une très grande quantité de RAM, un petit incident peut se transformer en une panne majeure.

Vous ne voulez PAS que votre serveur doive écrire 1 To de RAM sur le disque en cas de problème temporaire ponctuel.S'il y a un problème récurrent, vous pouvez augmenter le fichier d'échange pour capturer un vidage complet.J'attendrais pour le faire jusqu'à ce que PSS (ou quelqu'un d'autre qualifié pour analyser un vidage complet) vous demande de capturer un vidage complet.Un très petit pourcentage d’administrateurs de bases de données savent comment analyser un vidage complet.Un mini-dump est suffisant pour résoudre la plupart des problèmes qui surviennent de toute façon.

De plus, si votre serveur est configuré pour autoriser un vidage complet de 1 To et qu'un problème récurrent se produit, quelle quantité d'espace disque libre recommanderiez-vous d'avoir sous la main ?Vous pourriez remplir un SAN entier en un seul week-end.

Un fichier d'échange avec 1,5 * RAM était la norme à l'époque où vous aviez la chance d'avoir un serveur SQL avec 3 ou 4 Go de RAM.Ce n’est plus le cas.Je laisse le fichier d'échange à la taille et aux paramètres par défaut de Windows sur tous les serveurs de production (à l'exception d'un serveur SSAS qui subit une pression mémoire).

Et juste pour clarifier, j'ai travaillé avec des serveurs allant de 2 Go de RAM à 2 To de RAM.Après plus de 11 ans, il me suffit d'augmenter le fichier d'échange pour capturer une seule fois un vidage complet.

Answer 3

Selon Microsoft, "à mesure que la quantité de RAM dans un ordinateur augmente, la nécessité d'un fichier de page diminue". L'article continue ensuite à décrire comment utiliser les journaux de performances pour déterminer la quantité de fichier de page en fait utilisé.Essayez de définir votre fichier d'échange sur 1,5X de mémoire système pour commencer, puis effectuez la surveillance recommandée et effectuez les ajustements à partir de là.

Comment déterminer la taille de fichier d'échange appropriée pour les versions 64 bits de Windows

Answer 4

Plus il est grand, mieux c'est, jusqu'à la taille de l'ensemble de travail de l'application où vous commencerez à obtenir des rendements décroissants.Vous pouvez essayer de le trouver en augmentant ou en diminuant lentement la taille jusqu'à ce que vous constatiez un changement significatif dans les taux de réussite du cache.Cependant, si le taux de réussite du cache est supérieur à 90 %, tout va probablement bien.En règle générale, vous devez garder un œil sur cela sur un système de production pour vous assurer qu'il n'a pas dépassé son allocation de RAM.

Answer 5

Nous avons récemment rencontré des problèmes de performances avec l'un de nos serveurs SQL que nous n'avons pas pu résoudre complètement, et nous avons en fait utilisé l'un de nos tickets d'assistance Microsoft pour qu'ils nous aident à résoudre les problèmes.La taille optimale du fichier d'échange à utiliser avec SQL Server a été établie, et la recommandation de Microsoft est qu'elle soit 1 1/2 fois la quantité de RAM.

Answer 6

Si vous recherchez des performances élevées, vous souhaiterez éviter complètement la pagination, de sorte que la taille du fichier d'échange devient moins importante.Investissez dans autant de RAM que possible pour le serveur de base de données.

Answer 7

Après de nombreuses recherches, nos serveurs SQL dédiés exécutant Enterprise x64 sur Windows 2003 Enterprise x64 n'ont pas de fichier d'échange.

Simplement, le fichier d'échange est un cache pour les fichiers gérés par le système d'exploitation, et SQL possède son propre système de gestion de mémoire interne.

L'article MS référencé ne précise pas que les conseils s'adressent au système d'exploitation exécutant des services prêts à l'emploi tels que le partage de fichiers.

Avoir un fichier d'échange alourdit simplement les E/S du disque, car Windows essaie d'aider, alors que seul le système d'exploitation SQL peut faire le travail.

Answer 8

Dans ce cas, la recommandation normale de 1,5 fois la RAM physique totale n’est pas la meilleure.Cette recommandation très générale est fournie en supposant que toute la mémoire est utilisée par des processus « normaux », qui peuvent généralement voir leurs pages les moins utilisées déplacées vers le disque sans générer d'énormes problèmes de performances pour le processus d'application auquel appartient la mémoire.

Pour les serveurs exécutant SQL Server (généralement avec de très grandes quantités de RAM), la majorité de la RAM physique est réservée au processus SQL Server et doit être (si configurée correctement) verrouillée dans la mémoire physique, l'empêchant d'être paginée vers le fichier d'échange. .SQL Server gère sa propre mémoire avec beaucoup de soin en gardant à l'esprit les performances, en utilisant une grande partie de la RAM allouée à son processus comme cache de données pour réduire les E/S disque.Cela n'a pas de sens de transférer ces pages de cache de données vers le fichier d'échange, car le seul objectif d'avoir ces données dans la RAM est en premier lieu de réduire les E/S du disque.(Notez que le système d'exploitation Windows utilise également la RAM disponible de la même manière que le cache disque pour accélérer le fonctionnement du système.) Étant donné que SQL Server gère déjà son propre espace mémoire, cet espace mémoire ne doit pas être considéré comme « paginable » et n'est pas inclus dans un calcul pour le fichier d'échange. taille.

En ce qui concerne MEM_COMMIT mentionné par Remus, la terminologie prête à confusion car dans le langage de la mémoire virtuelle, « réservé » ne fait jamais référence à une allocation réelle, mais à l'interdiction d'utiliser un espace d'adressage (et non un espace physique) par un autre processus.La mémoire disponible pour être « validée » est fondamentalement égale à la somme de la RAM physique et de la taille du fichier d'échange, et effectuer un MEM_COMMIT décrémente simplement la quantité disponible dans le pool validé.Cela fait pas allouer une page correspondante dans le fichier d'échange à ce moment-là.Lorsqu'une page de mémoire réservée est réellement écrite, c'est à ce moment-là que le système de mémoire virtuelle allouera une page de mémoire physique et éventuellement déplacera une autre page de mémoire de la RAM physique vers le fichier d'échange.Voir MSDN Fonction VirtualAlloc référence.

Le système d'exploitation Windows suit les pressions de mémoire entre les processus d'application et son propre mécanisme de cache disque et décide quand il doit faire passer les pages de mémoire non verrouillées du physique au fichier d'échange.Je crois comprendre qu'avoir un fichier d'échange beaucoup trop volumineux par rapport à l'espace mémoire non verrouillé réel peut entraîner une pagination excessive de la mémoire des applications vers le fichier d'échange, ce qui fait que ces applications subissent les conséquences de pages manquées (performances lentes).

Tant que le serveur n'exécute pas d'autres processus gourmands en mémoire, une taille de fichier d'échange de 4 Go devrait suffire.Si vous avez configuré SQL Server pour autoriser le verrouillage des pages en mémoire, vous devez également envisager de définir le paramètre de mémoire maximale de SQL Server afin qu'il laisse une certaine RAM physique disponible au système d'exploitation pour lui-même et pour d'autres processus.

Les erreurs 802 dans SQL Server indiquent que le système ne peut plus valider de pages pour le cache de données.L'augmentation de la taille du fichier d'échange ne sera utile dans cette situation que dans la mesure où Windows est capable d'extraire la mémoire des processus non SQL Server.Permettre à la mémoire SQL Server de croître dans le fichier d'échange dans cette situation peut éliminer les messages d'erreur, mais cela est contre-productif, en raison du point précédent sur la raison du cache de données en premier lieu.