32
Chapitre 3. Optimisation du matériel
mémoire physique de même taille. Le processus de fenêtrage permet ensuite d’attribuer un espace à une région de mémoire, en balayage : toute la mémoire est accessible, mais pas en même temps. AWE est intéressant pour les applications qui
manipulent de larges volumes de données… comme un SGBDR.
S’agissant d’une API, il faut donc que le code de l’applicatif l’utilise. Vous devez
activer son utilisation dans SQL Server, à l’aide d’une option de configuration du
système.
sp_configure 'show advanced options', 1
RECONFIGURE
sp_configure 'awe enabled', 1
RECONFIGURE
La mémoire allouée par AWE est verrouillée en RAM et ne sera jamais échangée
(swappée) sur le disque. Elle ne pourra pas non plus être réclamée par le système
d’exploitation et est donc idéale pour gérer du cache. SQL Server l’utilise uniquement pour le buffer. En d’autres termes, en 32 bits, la mémoire au-delà de la limite
des 4 Go ne servira qu’au cache de pages de données. Tous les autres modules (la
mémoire de travail, les sessions, les verrous, le cache de plans d’exécution) devront
se placer dans l’espace d’adressage virtuel. C’est pour cette raison qu’il est important
de choisir l’option /3GB quand les conditions le permettent. Notez que AWE est
indépendant de PAE : il peut donc placer une partie du buffer aussi dans l’espace
d’adressage virtuel.
Prise en charge du 64 bits
Depuis la version 2000, SQL Server est livré en deux compilations pour les architectures de processeurs 32 bits (x86) et 64 bits (ia64 maintenant appelé Itanium, x64,
et amd64). Le choix d’une architecture 64 bits est de plus en plus intéressant,
notamment en rapport coût / performances, et vous devriez aller dans ce sens si vous
avez des besoins même moyennement importants. L’avantage, outre une capacité de
calcul plus importante des processeurs eux-mêmes, est la quantité de mémoire adressable par un pointeur 64 bits (donc 8 octets). Par défaut, l’espace d’adressage virtuel
pour les applications (user memory) est de 8 To (tera-octets), ou 7 To sur les processeurs Itanium, ce qui semble suffisant pour les quelques prochaines années. L’avantage ici est net pour SQL Server, et notamment pour la mémoire d’exécution et le
cache de plans, qui ne sont plus limités aux 2 ou 3 premiers Go comme en 32 bits.
Décisionnel – Le 64 bits est spécialement intéressant pour les services qui tournent autour
de SQL Server, comme Analysis Services ou Reporting Services. Ceux-ci n’utilisent pas AWE
et ne peuvent profiter de la mémoire supplémentaire en 32 bits. Ils restent tous en dessous
des 4 Go.
Bien entendu, l’option /3GB n’a pas de sens en 64 bits. En revanche, et cela peut
paraître étonnant, AWE peut se révéler intéressant, pour la raison que nous avons
déjà évoquée : comme il verrouille les pages en mémoire vive, elles ne peuvent être
Chapitre 3. Optimisation du matériel
mémoire physique de même taille. Le processus de fenêtrage permet ensuite d’attribuer un espace à une région de mémoire, en balayage : toute la mémoire est accessible, mais pas en même temps. AWE est intéressant pour les applications qui
manipulent de larges volumes de données… comme un SGBDR.
S’agissant d’une API, il faut donc que le code de l’applicatif l’utilise. Vous devez
activer son utilisation dans SQL Server, à l’aide d’une option de configuration du
système.
sp_configure 'show advanced options', 1
RECONFIGURE
sp_configure 'awe enabled', 1
RECONFIGURE
La mémoire allouée par AWE est verrouillée en RAM et ne sera jamais échangée
(swappée) sur le disque. Elle ne pourra pas non plus être réclamée par le système
d’exploitation et est donc idéale pour gérer du cache. SQL Server l’utilise uniquement pour le buffer. En d’autres termes, en 32 bits, la mémoire au-delà de la limite
des 4 Go ne servira qu’au cache de pages de données. Tous les autres modules (la
mémoire de travail, les sessions, les verrous, le cache de plans d’exécution) devront
se placer dans l’espace d’adressage virtuel. C’est pour cette raison qu’il est important
de choisir l’option /3GB quand les conditions le permettent. Notez que AWE est
indépendant de PAE : il peut donc placer une partie du buffer aussi dans l’espace
d’adressage virtuel.
Prise en charge du 64 bits
Depuis la version 2000, SQL Server est livré en deux compilations pour les architectures de processeurs 32 bits (x86) et 64 bits (ia64 maintenant appelé Itanium, x64,
et amd64). Le choix d’une architecture 64 bits est de plus en plus intéressant,
notamment en rapport coût / performances, et vous devriez aller dans ce sens si vous
avez des besoins même moyennement importants. L’avantage, outre une capacité de
calcul plus importante des processeurs eux-mêmes, est la quantité de mémoire adressable par un pointeur 64 bits (donc 8 octets). Par défaut, l’espace d’adressage virtuel
pour les applications (user memory) est de 8 To (tera-octets), ou 7 To sur les processeurs Itanium, ce qui semble suffisant pour les quelques prochaines années. L’avantage ici est net pour SQL Server, et notamment pour la mémoire d’exécution et le
cache de plans, qui ne sont plus limités aux 2 ou 3 premiers Go comme en 32 bits.
Décisionnel – Le 64 bits est spécialement intéressant pour les services qui tournent autour
de SQL Server, comme Analysis Services ou Reporting Services. Ceux-ci n’utilisent pas AWE
et ne peuvent profiter de la mémoire supplémentaire en 32 bits. Ils restent tous en dessous
des 4 Go.
Bien entendu, l’option /3GB n’a pas de sens en 64 bits. En revanche, et cela peut
paraître étonnant, AWE peut se révéler intéressant, pour la raison que nous avons
déjà évoquée : comme il verrouille les pages en mémoire vive, elles ne peuvent être