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

voix
16

Est-ce que tout flairer la bonne règle de base pour la taille de fichier d'échange approprié pour un SQL serveur exécutant Windows 2003 Server?

Créé 05/08/2008 à 18:07
source utilisateur
Dans d'autres langues...                            


8 réponses

voix
1

Si vous êtes à la recherche de haute performance, vous allez vouloir éviter la pagination complètement, de sorte que la taille du fichier de page devient moins importante. Investir dans autant de RAM que possible pour le serveur DB.

Créé 11/08/2008 à 13:22
source utilisateur

voix
2

Plus le mieux à la taille de l'ensemble de travail de l'application dans laquelle vous allez commencer à entrer dans des rendements décroissants. Vous pouvez essayer de trouver cela en augmentant ou en diminuant lentement la taille jusqu'à ce que vous voyez un changement significatif des taux de succès de cache. Toutefois, si le cache taux a atteint plus de 90% ou si vous êtes probablement OK. En général, vous devriez garder un oeil sur ce sur un système de production pour vous assurer qu'il n'a pas dépassé son allocation de RAM.

Créé 23/12/2008 à 15:45
source utilisateur

voix
2

Nous avions récemment quelques problèmes de performance avec l' un de nos SQL Server que nous n'avons pas pu complètement étroit vers le bas, et en fait utilisé l' un de nos billets de support Microsoft pour avoir les aider à résoudre. La taille optimale de fichier d' échange à utiliser avec SQL Server est venu, et la recommandation de Microsoft est que ce soit 1 1/2 fois la quantité de RAM .

Créé 10/09/2009 à 06:05
source utilisateur

voix
10

De la taille non pertinente de la RAM, vous avez encore besoin d'un fichier d'échange au moins 1,5 fois la quantité de RAM physique. Cela est vrai même si vous avez une machine à 1 RAM TB, vous aurez besoin de 1,5 TB sur pagefile disque (semble fou, mais il est vrai).

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

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

Nu quelques rares cas extrêmes, SQL Server toujours demander des pages MEM_COMMIT. Et compte tenu du fait que SQL utilise une gestion de la mémoire dynamique politique qui se réserve dès le départ le plus pool de mémoire tampon possible (réserves et engage en termes de VAS), SQL Server demandera au démarrage d' une énorme réserve d'espace dans le fichier d' échange. Si le fichier d' échange est pas correctement les erreurs de taille 801/802 commenceront à apparaître dans le fichier ERRORLOG de SQL et des opérations.

Cela provoque toujours une certaine confusion, car les administrateurs croient à tort qu'une grande RAM élimine le besoin d'un fichier d'échange. En vérité, le contraire se produit, une grande RAM augmente le besoin de fichier d'échange, juste à cause du fonctionnement interne du gestionnaire de mémoire Windows NT. Le fichier d'échange réservé est, espérons-le, jamais utilisé.

Créé 22/11/2009 à 23:11
source utilisateur

voix
3

Selon Microsoft, « comme la quantité de RAM dans un ordinateur augmente, le besoin d'un fichier de page diminue. » L'article continue ensuite de décrire comment utiliser les journaux de performance pour déterminer la quantité du fichier de page est en fait utilisé. Essayez de configurer votre fichier de page à la mémoire du système 1.5X pour commencer, puis faire le suivi recommandé et faire des ajustements à partir de là.

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

Créé 03/08/2010 à 19:58
source utilisateur

voix
1

Après beaucoup de recherches nos serveurs dédiés SQL exécutant l'Enterprise x64 sur Windows 2003 Enterprise x64 ont aucun fichier de page.

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

L'article fait référence MS ne se qualifie pas que le conseil est pour le système d'exploitation en cours d'exécution hors-the-box services tels que le partage de fichiers.

Avoir un fichier de page alourdit simplement le disque d'E / S parce que Windows essaie d'aider, lorsque seul le système d'exploitation SQL peut faire le travail.

Créé 24/05/2011 à 13:47
source utilisateur

voix
11

Avec tout le respect dû à Remus (que je respecte beaucoup), je suis en désaccord fortement. Si votre fichier de page est assez grand pour soutenir une décharge complète, il effectuera une décharge complète à chaque fois. Si vous avez une très grande quantité de RAM, cela peut provoquer un petit blip à une panne majeure est devenu.

Vous ne voulez pas que votre serveur d'avoir à écrire 1 To de RAM sur le disque s'il y a un problème transitoire unique. S'il y a un problème récurrent, vous pouvez augmenter le fichier de page pour capturer une image complète. Je hâte de le faire jusqu'à ce que vous avez été isntructed par PSS (ou quelqu'un d'autre qualifié pour analyser une décharge complète) vous demande de capturer une image complète. Un pourcentage extrêmement faible de CBM savoir comment analyser une décharge complète. Un mini-décharge est sufficent pour résoudre la plupart des problèmes qui apparaissent de toute façon.

De plus, si votre serveur est configuré pour permettre une décharge complète de 1 To et un problème récurrent se produit, comment l'espace disque libre beaucoup recommanderiez-vous d'avoir à portée de main? Vous pouvez remplir un SAN entier en un seul week-end.

Une page fichier 1.5 * RAM était la norme à l'époque où vous étiez la chance d'avoir un serveur SQL avec 3 ou 4 Go de RAM. Ce n'est pas plus le cas. Je laisse le fichier de page à la taille par défaut de Windows et les paramètres sur tous les serveurs de production (à l'exception d'un serveur SSAS qui connaît la pression de la 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, je n'ai dû increae le fichier d'échange pour capturer une décharge complète une fois.

Créé 05/10/2011 à 22:39
source utilisateur

voix
0

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

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 engagé dans le processus SQL Server et doit être (si elle est configurée correctement) verrouillé dans la mémoire physique, l'empêchant d'être paginée au fichier d'échange . SQL Server gère sa propre mémoire très soigneusement avec des performances à l'esprit, en utilisant une grande partie de la RAM allouée à son processus en tant que cache de données pour réduire E / S disque. Il n'a pas de sens à la page sur les pages de cache de données au fichier d'échange, comme le seul but d'avoir ces données dans la RAM en premier lieu est de réduire E / S disque. (Notez que le système d'exploitation Windows utilise également la RAM disponible de la même que le cache disque pour accélérer le fonctionnement du système.) Depuis SQL Server gère déjà son propre espace mémoire, cet espace mémoire ne doit pas être considérée comme « paginable », et non inclus dans le calcul de pagefile Taille.

En ce qui concerne MEM_COMMIT mentionné par Remus, la terminologie est source de confusion parce que , dans le jargon de la mémoire virtuelle, « réservé » ne se réfère à l' allocation réelle, mais d'empêcher l' utilisation d'un espace d'adressage (non de l' espace physique) par un autre processus. Mémoire disponible pour être « engagé » est essentiellement égale à la somme de RAM physique et la taille de fichier d' échange, et de faire un MEM_COMMIT décrémente juste le montant disponible dans la piscine engagée. Il ne pas allouer une page correspondante dans le fichier d' échange à ce moment - là. Lorsqu'une page de mémoire dédiée est en fait écrit à, c'est lorsque le système de mémoire virtuelle allouera une page de mémoire physique et peut - être une autre page de cogner la mémoire de RAM physique au fichier d' échange. Voir MSDN fonction VirtualAlloc de référence.

Le système d'exploitation Windows conserve la trace des pressions de mémoire entre les processus d'application et son propre mécanisme de cache disque et décide quand il doit cogner des pages de mémoire non verrouillés de physique au fichier d'échange. Je crois comprendre que d'avoir un fichier d'échange qui est trop grande par rapport à l'espace de mémoire non verrouillée réelle peut entraîner dans Windows pagination overzealously en mémoire d'application du fichier d'échange, ce qui dans les applications qui subissent les conséquences de la page misses (performance lente).

Tant que le serveur ne fonctionne pas d'autres processus gourmands en mémoire, une taille de fichier d'échange de 4 Go devrait être beaucoup. Si vous avez configuré SQL Server pour permettre les pages de verrouillage en mémoire, vous devez également envisager la mise en paramètre de mémoire maximum de SQL Server de sorte qu'il laisse un peu de RAM physique disponible pour le système d'exploitation pour lui-même et d'autres processus.

802 erreurs dans SQL Server indiquent que le système ne peut pas commettre de plus de pages pour le cache de données. L'augmentation de la taille du fichier d'échange seulement aider dans cette situation dans la mesure où Windows est capable à la page de la mémoire des processus de non-SQL Server. Permettre à la mémoire SQL Server pour se développer dans le fichier d'échange dans cette situation pourrait se débarrasser des messages d'erreur, mais il est contre-productif, en raison du point précédent sur la raison pour le cache de données en premier lieu.

Créé 04/04/2014 à 00:51
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more