Quelques faits sur le privilège Windows « Lock Page In Memory » et SQL Server
On trouve beaucoup d’articles traitant du privilège « Lock Page In Memory » et de SQL Server, mais ils prêtent souvent à confusion. Je vais essayer ici de clarifier les choses. Le but n’est pas ici de détailler les paramétrages mémoire de SQL Server mais de clarifier quelques concepts de base.
« Lock Page In Memory » est un privilège Windows, ce n’est pas une option de SQL Server.
Ce privilège peut être donné à un compte utilisateur Windows sur une machine donnée.
Il permet à un programme qui est conçu pour l’utiliser de bloquer tout ou partie de la mémoire qu’il s’alloue dans la mémoire physique et éviter que Windows mette cette mémoire dans le fichier de mémoire paginée sur le disque. Ce privilège ne changera donc pas le comportement d’un programme qui n’est pas conçu pour en tirer parti.
SQL Server est conçu pour fonctionner en utilisant ce privilège. Il est donc fortement conseillé de donner ce privilège au compte de service de SQL Server pour un fonctionnement optimal.
SQL Server utilise ce privilège de trois manières différentes :
· Pour allouer et gérer la mémoire de son pool de données
· En 32 bits pour exploiter la mémoire AWE
· En 64 bits pour optimiser sa gestion mémoire avec les allocations « Large-Page »
Allouer et gérer la mémoire de son pool de données
SQL Server quand il dispose de ce privilège, alloue la mémoire de son pool de données en demandant à Windows de n’utiliser que de la mémoire physique. Ceci permet à SQL Server de décider lui-même les informations pertinentes à conserver en mémoire de façon plus efficace que ne pourrait le faire le système.
Ceci pourrait gêner Windows lorsque la mémoire physique vient à manquer. Mais dans ce cas SQL Server libère de lui-même de la mémoire physique pour la restituer au système.
En revanche si SQL Server ne dispose pas de ce privilège, il ne peut garantir que la mémoire allouée ne soit pas transférer sur le disque. Dans ce cas les performances de SQL Server se trouvent très fortement dégradées, et peuvent saturer le système en cas de forte charge.
En 32 bits exploiter la mémoire AWE
En 32 bit, un programme ne peut allouer que 2 à 3 Go de RAM. SQL Server pour pouvoir exploiter plus de mémoire, utilise l'API « Address Windowing Extensions » (AWE) de Windows. Pour utiliser cette API le privilège « Lock Page In Memory » est requis par Windows. SQL Server a donc besoins de ce privilège pour utiliser plus de 2 à 3 Go de mémoire en 32 bits.
En 64 bits optimiser la gestion mémoire avec les allocations « LARGE PAGE »
Pour limiter la charge processeur lors des allocations et accès mémoire, SQL Server peut en 32 bits utiliser des allocations mémoire de type « Large-Page » en 64 bits. Pour utiliser cette fonctionnalité Windows API le privilège « Lock Page In Memory » est requis. SQL Server a donc besoins de ce privilège pour bénéficier de cette optimisation.
Pour en savoir plus :
Procédure : activer l'option Lock Pages in Memory (Windows)
https://msdn.microsoft.com/fr-fr/library/ms190730.aspx
Intel Physical Addressing Extensions (PAE) in Windows 2000
https://support.microsoft.com/kb/268363/en-us
Procédure : configurer l'option awe enabled (SQL Server Management Studio)
https://msdn.microsoft.com/fr-fr/library/ms190961.aspx
Large-Page Support
https://msdn.microsoft.com/en-us/library/aa366720(VS.85).aspx
Pascal Deliot