34
Chapitre 3. Optimisation du matériel
(être NUMA-aware) pour configurer l’exécution de leur threads par nœuds NUMA.
Les applications qui ne reconnaissent pas NUMA peuvent être ralenties, à cause des
différences de temps pour accéder à des parties de mémoires situées sur des bus différents.
Pourquoi AWE est-il intéressant avec NUMA ? Comme le PFN (stocké dans la
PTE, comme nous l’avons vu) montre à quel nœud NUMA appartient la page de
mémoire, la lecture de cette information (à l’aide de l’API QueryWorkingSetEx depuis
le Service Pack 1 de Windows Server 2003) nécessite une attribution et une libération de verrou. De plus, cette lecture doit être réalisée périodiquement, afin de prendre en compte les changements d’attribution physique de la page, qui peuvent
résulter d’une pagination sur le disque. AWE verrouille les pages en mémoire, ce qui
garantit donc qu’elles ne seront jamais paginées. Ainsi, une application NUMAaware n’a besoin de récupérer l’attribution physique d’une page qu’une seule fois, sur
de la mémoire AWE.
Soft-NUMA
Pour tester l’implémentation de leur moteur sous NUMA, les équipes de développement de
SQL Server 2005 ont bâti une version logicielle de l’architecture NUMA, qui en simule
l’architecture matérielle. Ils se sont aperçus que cette implémentation logicielle améliorait les
performances sur les systèmes multiprocesseurs SMP, et même NUMA. Cet outil fait à la
base pour le test, est donc passé en production sous le nom de soft-NUMA. Si vous avez au
moins 8 processeurs, essayez de configurer soft-NUMA pour SQL Server, et comparez les
performances. Pour ce faire, vous créez des affinités de processeurs par nœuds soft-NUMA
dans la base de registre, dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\90\NodeConfiguration\. Pour les informations pratiques, reportez-vous aux BOL,
section « How to : Configure SQL Server to Use Soft-NUMA »
Pression sur la mémoire
SQL Server réagit à la pression sur la mémoire, c’est-à-dire au manque de mémoire
lorsque celle-ci est réclamée par des processus. Elle peut libérer des espaces mémoire
qui étaient utilisés, par exemple par le cache de données ou le cache de procédures.
En 32 bits, le cache de données peut résider dans la mémoire gérée par AWE, mais
tout le reste doit être dans l’espace d’adressage virtuel, en dessous de la limite des
4 Go. Vous pouvez déterminer s’il manque de la mémoire pour le cache de données
en surveillant les compteurs de performances de l’objet SQL:Buffer Manager :
• Buffer cache hit ratio – Pourcentage de pages qui ont pu être servies du
cache, sans être cherchées sur le disque.
• Page life expectancy – Nombre de secondes durant lesquelles une page non
utilisée reste dans le cache.
• Stolen pages – Nombre de pages « volées » du cache pour être utilisées
ailleurs.
Nous détaillons ces compteurs dans la section 5.3.1. Buffer cache hit ratio
doit être élevé (plus de 97 %). Plus Page life expectancy est élevé, mieux c’est :
Chapitre 3. Optimisation du matériel
(être NUMA-aware) pour configurer l’exécution de leur threads par nœuds NUMA.
Les applications qui ne reconnaissent pas NUMA peuvent être ralenties, à cause des
différences de temps pour accéder à des parties de mémoires situées sur des bus différents.
Pourquoi AWE est-il intéressant avec NUMA ? Comme le PFN (stocké dans la
PTE, comme nous l’avons vu) montre à quel nœud NUMA appartient la page de
mémoire, la lecture de cette information (à l’aide de l’API QueryWorkingSetEx depuis
le Service Pack 1 de Windows Server 2003) nécessite une attribution et une libération de verrou. De plus, cette lecture doit être réalisée périodiquement, afin de prendre en compte les changements d’attribution physique de la page, qui peuvent
résulter d’une pagination sur le disque. AWE verrouille les pages en mémoire, ce qui
garantit donc qu’elles ne seront jamais paginées. Ainsi, une application NUMAaware n’a besoin de récupérer l’attribution physique d’une page qu’une seule fois, sur
de la mémoire AWE.
Soft-NUMA
Pour tester l’implémentation de leur moteur sous NUMA, les équipes de développement de
SQL Server 2005 ont bâti une version logicielle de l’architecture NUMA, qui en simule
l’architecture matérielle. Ils se sont aperçus que cette implémentation logicielle améliorait les
performances sur les systèmes multiprocesseurs SMP, et même NUMA. Cet outil fait à la
base pour le test, est donc passé en production sous le nom de soft-NUMA. Si vous avez au
moins 8 processeurs, essayez de configurer soft-NUMA pour SQL Server, et comparez les
performances. Pour ce faire, vous créez des affinités de processeurs par nœuds soft-NUMA
dans la base de registre, dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\90\NodeConfiguration\. Pour les informations pratiques, reportez-vous aux BOL,
section « How to : Configure SQL Server to Use Soft-NUMA »
Pression sur la mémoire
SQL Server réagit à la pression sur la mémoire, c’est-à-dire au manque de mémoire
lorsque celle-ci est réclamée par des processus. Elle peut libérer des espaces mémoire
qui étaient utilisés, par exemple par le cache de données ou le cache de procédures.
En 32 bits, le cache de données peut résider dans la mémoire gérée par AWE, mais
tout le reste doit être dans l’espace d’adressage virtuel, en dessous de la limite des
4 Go. Vous pouvez déterminer s’il manque de la mémoire pour le cache de données
en surveillant les compteurs de performances de l’objet SQL:Buffer Manager :
• Buffer cache hit ratio – Pourcentage de pages qui ont pu être servies du
cache, sans être cherchées sur le disque.
• Page life expectancy – Nombre de secondes durant lesquelles une page non
utilisée reste dans le cache.
• Stolen pages – Nombre de pages « volées » du cache pour être utilisées
ailleurs.
Nous détaillons ces compteurs dans la section 5.3.1. Buffer cache hit ratio
doit être élevé (plus de 97 %). Plus Page life expectancy est élevé, mieux c’est :