Discussion :

[Baquardie]

Bonjour,

J'ai un serveur 2008 64 bits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT @@VERSION
 
Microsoft SQL Server 2008 (SP2) - 10.0.4000.0 (X64)   Sep 16 2010 19:43:16   Copyright (c) 1988-2008 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: ) (VM)

Et mon application Idera m'envoie constamment un alerte comme quoi l'utilisation de la mémoire est de 95%.

Lorsque j'ouvre le Windows Task Manager, effectivement, la mémoire est très utilisée. Voici les infos que j'y lis :

Physical Memory (MB)
Total : 7935
Cached : 277
Available : 319
Free : 43

Et lorsque je regarde le tab "Processes", sqlservr.exe prend 6,515,028K de mémoire.

Du côté de mon serveur, j'ai assigné une valeur maximale d'utilisation de la mémoire à 6144MB (c'était déjà en place).

Tout les autres serveurs sql n'ont pas une utilisation aussi haute de la mémoire. Je me demandais si je devais prendre action (suite à l'alerte de mon application Idera).

J'ai lu sur le forum que sql prenait parfois toutes les ressources lorsque besoin mais ne relâchais pas par la suite, et que donc, si on voulait faire baisser l'utilisation de la mémoire, il fallait changer les valeurs de "max server memory" et ensuite le remettre au maximum (laisser 10% de libre pour le OS).

Merci pour votre aide,

Baq'

[dbaffaleuf]

SQL Server restitue bien la mémoire lorsque Windows le lui demande, depuis Windows 2003 et SQL Server 2005 RTM. Pour connaître l'espace mémoire libre, il faut sampler le compteur perfmon '\Memory\Available MBytes'. Pour l'espace libre à laisser à l'OS, cf http://sqlserverperformance.wordpres...rver-20052008/

[Baquardie]

ok merci.

Je viens de baisser l'utilisation de la mémoire en changeant la valeur de mon max memory :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
EXEC  sp_configure 'max server memory (MB)',3200;
GO
RECONFIGURE;
GO

En très peu de temps, mon pourcentage de mémoire physique utilisé a descendu.

Maintenant, il est de 60%, et le tableau du Windows Task Manager présente ceci :

Physical Memory (MB)
Total : 7935
Cached : 179
Available : 2009
Free : 2829

Ce qui est mieux. J'ai ensuite remis ma valeur maximal de memoire à environ 10% de ma ram :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
EXEC  sp_configure 'max server memory (MB)',6400;
GO
RECONFIGURE;
GO

Je verrai au courant des prochains jours comment se comporte la RAM.

Merci !

[dbaffaleuf]

Il faut regarder la tendance du compteur '\SQL Server:Buffer Manager\Page Life Expectancy' ou 'Espérance de vie d'une page' sur une instance FR. il indique la durée moyenne pendant laquelle une page reste en cache. Si la valeur est très basse, celà peut indiquer que SQL Server ne dispose pas de suffisamment de mémoire. Si tu observes de brusques variations dans ce compteur, ou systématiquement une valeur basse (fonction de la quantité de mémoire sur ta machine, disons moins de 1000 secondes), là SQL est trop bridé, donc il faut :
1) regarder quelles sont les requêtes qui font le plus d'IOs (et qui potentiellement ravagent le buffer pool)
2) upgrader la mémoire sur la machine, augmenter max server memory.

Je te recommande au passage d'activer le verrouillage de pages, celà évitera que windows pagine l'espace mémoire alloué par SQL Server. cf http://msdn.microsoft.com/en-us/library/ms190730.aspx

[Baquardie]

Merci pour la réponse, je vais aller de ce pas monitorer ce compteur puisque l'utilisation de la mémoire est déjà revenue à ce qu'elle était, c'est à dire 96% d'utilisation.

[Baquardie]

Je te recommande au passage d'activer le verrouillage de pages, celà évitera que windows pagine l'espace mémoire alloué par SQL Server. cf http://msdn.microsoft.com/en-us/library/ms190730.aspx

Je n'ai pas besoin puisque mon système est 64 bits.

[dbaffaleuf]

Je n'ai pas besoin puisque mon système est 64 bits.

C'est justement parce que tu es en 64 bits qu'il faut le faire.

[Baquardie]

C'est justement parce que tu es en 64 bits qu'il faut le faire.

Il y a surement quelque chose que je ne comprend pas, parce que sur le lien que vous m'avez fourni, lorsque je sélectionne SQL Server 2008, c'est écrit :

Locking pages in memory is not required on 64-bit operating systems.

[dbaffaleuf]

Il y a surement quelque chose que je ne comprend pas, parce que sur le lien que vous m'avez fourni, lorsque je sélectionne SQL Server 2008, c'est écrit :

Cette phrase hors contexte prête en effet à confusion, c'est la raison pour laquelle elle a été retirée sur la page correspondant à SQL 2012. Elle fait référence à l'activation d'AWE qui en 32 bits nécessite 2 actions:
- Activer le paramètre 'awe enabled'
- Granter le privilège système 'Lock Pages in Memory' au compte de service de SQL Server.

Or AWE en 64 bits n'a pas de sens direct, car le paramètre 'awe enabled' est complètement ignoré au démarrage.

Je te confirme qu'il est recommandé d'activer 'Lock Pages in Memory' sur un SQL Server 64 bits et de fixer une valeur de 'max server memory' pour deux raisons principales:

- Au démarrage de SQL Server, si le compte de service possède le privilège 'Lock Pages in memory', la méthode d'allocation de la mémoire sera différente de celle qui serait utilisée normalement, et plus optimisée, car elle préalloue de grosses 'régions' de mémoire physique et celà nécessite moins de synchronisation avec le kernel. Dans la mesure où il s'agit de mémoire physique, donc non paginable, elle doit être verrouillée en mémoire d'où le privilège.
- La deuxième raison est qu'on ne souhaite pas que Windows se mette à paginer de la mémoire de SQL Server car cela va poser de gros problèmes de performance. Souvent on voit cette situation avec un message loggé dans l'errorlog:

A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): ..., committed (KB): ..., memory utilization: ...%.

Le verrouillage des pages empêche ce phénomène. En même temps on ne souhaite pas se tirer une balle dans le pied en empêchant windows de pouvoir paginer si le besoin existe. Donc on limite SQL Server en espace maximum utilisé pour que la situation ne se produise jamais.

Bottomline: en 64 bits il faut les deux prérequis: max server memory + Lock Pages in Memory.

[elsuket]

Bonjour,

Au démarrage de SQL Server, si le compte de service possède le privilège 'Lock Pages in memory', la méthode d'allocation de la mémoire sera différente de celle qui serait utilisée normalement, et plus optimisée, car elle préalloue de grosses 'régions' de mémoire physique et celà nécessite moins de synchronisation avec le kernel.

La documentation de SQL Server à ce sujet me semble floue et les rares billets que l'on trouve ici et là (avec les liens vers d'autres billets) m'ont laissé dans le doute.

Ce que j'ai compris c'est que l'on doit, bien sûr, accorder le soin requis à la configuration de l'option max server memory en fonction de ce qui est sur le serveur (autre que SQL Server), mais aussi en fonction des fonctionnalités de SQL Server que l'on va utiliser (SSIS, Full-Text Search, ...)
Ce que je fais donc quand on me demande d'installer SQL Server 2008 sur un Windows 2008 (R2 ou pas), c'est d'exagérer la valeur de cette option un peu trop basse, puis lors des tests d'avant-production (quand on m'en donne l'occasion), monter progressivement sa valeur en suivant le compteur de performances Memory\Available Mbytes (ce que fait apparemment Jonathan Kehayias), Free Pages, et Free Page Stalls

Donc je n'ai jamais eu de réponse vraiment concrète concernant ce privilège, alors j'aimerai avoir des retours d'expérience, en considérant une installation de Windows Server 2008 et de SQL Server 2008 (R2 ou pas), pour des serveurs disposant toujours d'au moins 64GB de RAM.

@++

[mikedavem]

L'allocation des pages larges se fait de manière contigue en mémoire. Cela signifie qu'après un temps de fonctionnement du serveur assez long il y a de grandes changes que cette allocation ne puisse se faire correctement.

En principe sur un serveur SQL dédié cela reste efficace car il n'y a que le processus liée à une instance SQL Server qui est censé s'accaparer de la mémoire.

Le lien msdn suivant explique qu'il faut avoir le privilèges "Locked Pages In Memory" pour pouvoir bénéfier du support des pages larges.

++

[dbaffaleuf]

L'allocation des pages larges se fait de manière contigue en mémoire. Cela signifie qu'après un temps de fonctionnement du serveur assez long il y a de grandes changes que cette allocation ne puisse se faire correctement.

En principe sur un serveur SQL dédié cela reste efficace car il n'y a que le processus liée à une instance SQL Server qui est censé s'accaparer de la mémoire.

Le lien msdn suivant explique qu'il faut avoir le privilèges "Locked Pages In Memory" pour pouvoir bénéfier du support des pages larges.

++

Hello Mike, pourquoi Large Pages ? Dans le cas de Baquardie il n'y a pas d'utilisation des larges pages pour le BP, il faudrait activer le TF834 pour ça.

[dbaffaleuf]

Bonjour,


La documentation de SQL Server à ce sujet me semble floue et les rares billets que l'on trouve ici et là (avec les liens vers d'autres billets) m'ont laissé dans le doute.

Ce que j'ai compris c'est que l'on doit, bien sûr, accorder le soin requis à la configuration de l'option max server memory en fonction de ce qui est sur le serveur (autre que SQL Server), mais aussi en fonction des fonctionnalités de SQL Server que l'on va utiliser (SSIS, Full-Text Search, ...)
Ce que je fais donc quand on me demande d'installer SQL Server 2008 sur un Windows 2008 (R2 ou pas), c'est d'exagérer la valeur de cette option un peu trop basse, puis lors des tests d'avant-production (quand on m'en donne l'occasion), monter progressivement sa valeur en suivant le compteur de performances Memory\Available Mbytes (ce que fait apparemment Jonathan Kehayias), Free Pages, et Free Page Stalls

Donc je n'ai jamais eu de réponse vraiment concrète concernant ce privilège, alors j'aimerai avoir des retours d'expérience, en considérant une installation de Windows Server 2008 et de SQL Server 2008 (R2 ou pas), pour des serveurs disposant toujours d'au moins 64GB de RAM.

@++

Concernant le besoin d'avoir le privilège, c'est simple. Si le compte de service ne dispose pas du privilège, SQLOS va gérer la mémoire à coups de VirtualAlloc() successifs au fur et à mesure qu'il recalcule son target (total -> target). S'il dispose du privilège il va se passer deux choses:
- le large page allocator est initialisé, et sera utilisé pour effectuer certaines actions très précises, comme par exemple limiter les TLB misses en stockant des structures ultra accédées (un objet de synchro utilisés dans un spinlock par exemple, le truc qui doit être accédé le plus vite possible au niveau du code)
- la mémoire va être allouée en utilisant les mêmes primitives que pour AWE en 32 bits, c'est à dire de la pagination mémoire. L'intérêt c'est que cette allocation est effectuée une seule fois par région, et ne nécessite que très peu de synchronisation avec le memory manager de windows.

Donc ce sera plus performant. La contrepartie comme expliqué à Baquardie, c'est de ne pas pousser windows à la faillite mémoire, donc placer une réserve en fonction de la mémoire physique disponible. Tu peux trouver les différentes valeurs testées par Glenn dans son post indiqué plus haut.

A+

[mikedavem]

Hello Mike, pourquoi Large Pages ? Dans le cas de Baquardie il n'y a pas d'utilisation des larges pages pour le BP, il faudrait activer le TF834 pour ça.

Quand on active le privilège Locked Pages in Memory on active bien le support des pages larges indépendemment du trace flag 834. On peut le voir d'ailleurs dans le log SQL Server. Bien entendu il faut que les conditions suivantes soient reunis :

•SQL Server Enterprise Edition
•Avoir au moins 8Go ou plus
•“Lock Pages in Memory” privilege paramétré pour le compte de service

Le trace flag 834 (si je ne me trompe pas ) permet d'allouer en une seule fois le buffer pool au démarrage de l'instance pour éviter l'allocation des pages larges par VirtualAlloc() de façon répétée car ce type d'allocation peut être lent. Lors de la phase du RAM-UP celui-ci n'atteint pas la taille limite fixée et grossit éventuellement de manière dynamique en fonction de la charge.

++

[dbaffaleuf]

Quand on active le privilège Locked Pages in Memory on active bien le support des pages larges indépendemment du trace flag 834. On peut le voir d'ailleurs dans le log SQL Server. Bien entendu il faut que les conditions suivantes soient reunis :

•SQL Server Enterprise Edition
•Avoir au moins 8Go ou plus
•“Lock Pages in Memory” privilege paramétré pour le compte de service

OK mais le problème de contigüité que tu évoques a une probabilité quasi nulle de se produire sans le TF834, parce que c'est là qu'on a le plus de chance de mettre en évidence un problème de frag mémoire. Sans le traceflag les allocations en large pages sont insignifiantes comparées au BP.

Le trace flag 834 (si je ne me trompe pas ) permet d'allouer en une seule fois le buffer pool au démarrage de l'instance pour éviter l'allocation des pages larges par VirtualAlloc() de façon répétée car ce type d'allocation peut être lent.

Je pense qu'il y a confusion entre locked pages et large pages.

Le TF permet d'utiliser des large pages pour le buffer pool, tout allouer dès le départ est juste une stratégie, pas un objectif. La contrainte d'allouer des large pages est qu'une région allouée de cette façon doit être physiquement contigüe en mémoire (je ne parle pas d'adressage virtuel mais bien physique). SQL Server décide d'allouer tout dès le départ parce qu'il part du principe que la machine est 'cold' et que rien n'est alloué donc qu'il a plus de chances de trouver de grandes régions contigües. Si le TF834 n'est pas activé le buffer pool sera alloué en locked pages mais pas en large pages.

Quand tu dis que VirtualAlloc() peut être lent, là aussi peut être qu'il y a mélange entre locked pages et large pages. Je ne crois pas que prendre toute la mémoire dès le début soit plus rapide que prendre la même quantité petit à petit. Le démarrage d'un SQL Server avec le TF834 et un max server memory à 100Gb+ met des plombes à rendre la main, donc question vitesse...

Par contre, l'allocation via les locked pages et les apis AWE est plus rapide que via des VirtualAlloc() successifs, parce que quand tu alloues physiquement une région via une api AWE type AllocateUserPhysicalPages(), tu dois passer un pointeur vers un tableau contenant la liste des PFNs allouées, et donc tu ne touche le PFN Database Lock qu'une seule fois. Mais ça n'a rien à voir avec les large pages. La preuve c'est que ça fonctionnait déjà déjà comme ça en dynamic AWE 32 bits, et donc sans large pages.

Lors de la phase du RAM-UP celui-ci n'atteint pas la taille limite fixée et grossit éventuellement de manière dynamique en fonction de la charge.
++

Je ne vois pas trop à quoi tu fais allusion mais s'il s'agit de l'allocation en large pages dès le départ, une fois que SQL Server écrit "n Mb allocated using Large Pages" dans l'ERRORLOG, il n'ira pas plus loin, c'est une certitude, même s'il n'a pas atteint son target (max server memory, RAM, VAS...). C'est pour ça que le TF834 n'est pas conseillé si on redémarre SQL Server sans redémarrer la machine (clusters et compagnie), parce qu'il y a de bonnes chances pour que tu aies un ssms ou un autre trouble-fête en plein milieu de ton espace adressable, et que SQL Server s'arrête à 30Gb au lieu de 80Gb.

Bonne soirée

[mikedavem]

Ok, autant pour moi David, j'ai confondu 2 choses importantes ici après relu la doc :

--> LargePagesAllocator qui permet d'activer le support des larges pages avec SQL Server (disponible après avoir activer le privilège SetLockedPagesInMemory)

--> Le trace flag 834 qui permet d'utiliser ce support pour le buffer pool.

++

[dbaffaleuf]

Ok, autant pour moi David, j'ai confondu 2 choses importantes ici après relu la doc :

--> LargePagesAllocator qui permet d'activer le support des larges pages avec SQL Server (disponible après avoir activer le privilège SetLockedPagesInMemory)

--> Le trace flag 834 qui permet d'utiliser ce support pour le buffer pool.

++

Pas de pb, en fait je suis en plein sur un pb de TF834 chez un client en ce moment, donc j'ai passé pas mal de temps à gratter autour...

[elsuket]

Merci à tous les deux de vos retours

@++