Après avoir effectué des audits sur 2 serveurs de bases de données chez mon client, j’ai constaté qu’il y avait quelques confusions concernant les options bien connus /3GB et /PAE qui permettent d’étendre la mémoire vue et utilisée par le système d’exploitation et les applications. Les questions qui reviennent souvent sont les suivantes : Quand utiliser l’option /3GB ? Quand utiliser l’option /PAE ? Peux t’on utiliser les 2 options en même temps ? Nous allons y répondre .

Pour savoir quel commutateur choisir selon le cas, voyons tout d’abord comment ceux-ci fonctionnent. Je rappelle tout d’abord que ces commutateurs sont extrêmement utilisés avec les architectures 32 bits. Pourquoi ? Parce que la quantité de mémoire maximum que peut voir un système basé sur une architecture 32 bits correspond à 2^32  soit 4 Go de mémoire. Ces 4Go d’espace mémoire sont partagés entre le noyau du système d’exploitation ou kernel et les processus utilisateurs. Ce partage est équitable : 2 Go sont réservés à l’usage des processus du noyau et les 2 autres à l’usage des processus utilisateurs. Le processus sqlservr.exe fait parti des processus utilisateurs. Cela veut dire que SQL Server ne pourra utiliser au grand maximum que 2 Go de RAM qu’il faudra partager avec ses différents caches.

Heureusement pour nous il existe 2 commutateurs pouvant outrepasser cette limite. Le premier commutateur /3GB permet de réserver dans l’espace d’adresses virtuelles plus de place pour les applications. Le partage se fait de la manière suivante : 1Go pour le noyau du système d’exploitation et 3 Go pour les applications. Cela signifie que la quantité d’espace d’adresses virtuelles que peut utiliser SQL Server passe à 3Go et on gagne donc 1Go. Il est possible d’affiner cette allocation en utilisant conjointement le commutateur /USERVA. Par exemple /USERVA=2560 signifie que 2.5Go seront réservés aux processus utilisateurs et 512Mo seront réalloués au noyau.

 

 

Le 2ème commutateur /PAE, quant à lui, permet d’étendre l’espace mémoire physique au delà de la limite des 4Go et jusqu’à 64 Go. Une unité de gestion de mémoire est le composant responsable de l’accès mémoire demandé par un processeur. Par défaut ce composant possède des lignes d’adressage qui peuvent gérer jusqu’à 2^32 bits soit 4Go de mémoire. En mode PAE (Physical Address Extension), ce composant se voit rajouter des lignes d’adressage qui permettent cette fois ci de gérer 2^36 bits soit 64Go. Le système d’exploitation voit donc la mémoire au delà des 4Go. Cependant l’activation du mode PAE ne suffit pas pour que SQL Server puisse accéder à cette quantité de mémoire supplémentaire. En effet SQL Server comme toute application reste également limitée par sa capacité d’adressage. L’API AWE (Address Windowing Extensions) permet à une application d’accéder à la mémoire au delà des 32 bits. Les choses étant bien faites, SQL Server permet l’utilisation de cette API et peut ainsi profiter de la mémoire au delà des 4Go en activant l’option de serveur awe enabled.

Maintenant que nous savons comment fonctionnent les options /3GB et /PAE on peut se poser la question qui est de savoir si ces 2 options peuvent être utilisés conjointement. La réponse est oui mais dans certaines situations bien précises. En effet l’option /3GB permet d’allouer plus d’espace d’adresses virtuelles aux applications au détriment du noyau dans la limite des 4Go alors l’option /PAE permet d’outrepasser cette limite physique des 4Go. Prenons par exemple le cas où notre serveur possède 20Go de RAM. Une idée serait d’activer les 2 options pour que SQL Server puisse profiter au maximum de la mémoire (20Go – 1Go pour le noyau soit 19Go). Mais ce n’est pas aussi simple en réalité. Au delà de 16Go de RAM, le système d’exploitation a besoin d’1 Go supplémentaire pour pouvoir gérer les pages de tables (PTE). Ces pages de table sont des structures virtuelles permettant de mapper une adresse virtuelle à une adresse physique. Si le commutateur /3GB est activée en même temps que le commutateur /PAE dans ce cas précis, la mémoire supplémentaire est ignorée.

Pour résumé voici en fonction de la quantité de mémoire les commutateurs que l’on peut activer :

 

Attention également à l’utilisation de ces options avec les différentes versions de SQL Server et de Windows. Je vois au cours de mes audits certaines erreurs de la part de certains fournisseurs qui veulent augmenter la mémoire d’un serveur sans savoir qu’une version de Windows ou de SQL Server ne pourra pas en profiter. D’une manière générale, pour utiliser la mémoire au delà des 4Go une version entreprise ou ultérieure est nécessaire en ce qui concerne le système d’exploitation et une version entreprise ou développeur est nécessaire pour ce qui concerne SQL Server. Pour l’option /3GB la version de SQL Server est importante (SQL Server 2000 standard par exemple ne supporte pas plus de 2Go de mémoire alors qu’une version standard de 2005 n’est limitée que par les capacités du système d’exploitation). Un tableau récapitulatif se trouve sur le blog de Christian Robert.

David BARBARIN (Mikedavem)
Elève ingénieur CNAM Lyon