Il n’y a pas si longtemps chez un client, j’ai été confronté à un problème de pagination mémoire (swaping) sur un cluster Oracle 11gR2 ce qui a nécessité malheureusement et malencontreusement d’arrêter la totalité du cluster pour que les performances redeviennent acceptables.

Hormis le fait que nous envisagions d’augmenter la mémoire physique de chacun des noeuds du cluster il s’avère indispensable de repousser et d’éviter ce mécanisme indésirable de pagination.

Sous Linux 64 bits la mémoire est gérée à travers des pages mémoire de 4K. Avec la demande croissante de besoin en mémoire des systèmes qui actuellement excède fréquemment 64 Go, la gestion des pages standards devient de plus en plus gourmande en terme d’entrées dans la table des pages mémoire ce qui impacte directement l’utilisation des cycles du processeur lors des accès à la mémoire.

Ainsi les hugepages permettent de gérer la mémoire non plus avec des pages de 4K mais avec des pages d’une taille bien supérieure en général de 2 Mo sous la plupart des Linux.

 Les deux intérêts principaux de l’utilisation des hugepages par Oracle sont :

1.  Le cache Oracle est verrouillé en mémoire physique ce qui évite tout risque de pagination.
2.  L’optimisation de la gestion de la table des pages mémoire (pagetables) qui effectue la translation entre la mémoire virtuelle et la mémoire physique. Du fait de la taille de 2 Mo des hugepages le nombre d’entrées à gérer dans cette table des pages mémoire est  divisé par 512 par rapport à des pages standards de 4K, le gain n’est pas négligeable surtout en ce qui concerne la sollicitation du processeur pour accéder à la mémoire.

Limites de l’utilisation des Hugepages avec Oracle

• La note Oracle 1392497.1 sur MOS précise explicitement que la gestion automatique et dynamique de la mémoire (AMM) via les paramètres MEMORY_TARGET , MEMORY_MAX_TARGET de la release 11gR2 est incompatible avec l’utilisation des hugepages.

•  Si nous allouons des hugepages à Oracle et qu’il n’y ait pas assez de hugepages disponibles pour monter la totalité de la mémoire dédiée à l’instance Oracle, dans ce cas en version 11.2.0.2 Oracle utilisera par défaut l’espace mémoire géré par des pages standards.

• Pour l’instance ASM nous utiliserons la gestion des pages standards qui nous autorise à utiliser la gestion automatique et dynamique de la mémoire (AMM) proposée en 11.2.0.2 par Oracle

Mise en oeuvre des Hugepages

Cette mise en oeuvre nécessite d’intervenir aussi bien sur la configuration système que sur celle d’Oracle.

Configuration système

Nous retiendrons la méthode statique en ajoutant les paramètres hugepages dans les fichiers de configuration et en rechargeant la configuration par sysctl –p mais un reboot du serveur s’impose car bien souvent la mémoire est déjà utilisée et seulement une fraction des pages risquent d’être allouées pour cette nouvelle méthode de gestion mémoire.

Fichier de configuration : /etc/sysctl.conf

• kernel.shmmax définit la taille maximale d’un segment de mémoire partagée et doit être initialisé à la valeur maximale  associée au paramètre SGA_TARGET sur le serveur plus 1 Go. Ainsi pour une instance de 100 Go maximum ce paramètre devrait être initialisé à 101 Go soit 108447924224

• kernel.shmall définit la somme des segments de mémoire partagée alloués à un utilisateur. Cette valeur est exprimée en page mémoire (getconf pagesize). Ce paramètre doit être initialisé à la somme des valeurs de SGA_TARGET divisé par la taille de la page mémoire. La page standard sur Linux est 4K aussi ce paramètre devrait être 26476544 (108447924224/4096)
• vm.nr_hugepages définit le nombre de pages qui sont allouées sur le serveur. Ce nombre de hugepages requises est déterminé par la somme des mémoires partagées Oracle hébergées sur le serveur (La valeur de SGA_MAX_SIZE normalement ou la somme de ce paramètre si le serveur héberge plusieurs instances) et divisé par la taille d’une hugepage 2048k ou 2Mo sous Linux. Il est conseillé d’adjoindre 5 pages supplémentaires pour Oracle, nous avons alors la formule suivante pour une SGA de 64 Go : (64*1024*1024/2048)+5=32773

• vm.hugetlb_shm_group définit le groupe ID des Hugepages pour lequel les utilisateurs ayant le même groupe ID sont autorisés, nous mettrons le groupe id du groupe DBA dans une configuration standard, en revanche dans une configuration RAC ce paramètre doit être initialisé au groupe ID de l’utilitaire srvctl car c’est le clusterware sous le compte root  qui démarre l’instance avec un bit setuid et si ce paramètre n’est pas positionné correctement, les HugePages seront utilisées avec srvctl mais pas avec sqlplus.

Fichier de sécurité : /etc/security/limits.conf

• oracle soft memlock
• oracle hard memlock

Ces deux paramètres devraient prendre une valeur légèrement inférieure au total de la mémoire physique installée sur le serveur Oracle de 144 Go dont nous disposons soit 140 Go. Cette valeur est exprimée en Ko aussi le nombre à initialisé pour ces deux paramètres est 140000000 ce qui correspond au volume total de mémoire qu’Oracle est autorisé à verrouiller.
Mémoire  partagée gérée sous /dev/shm

Comme la mémoire partagée d’Oracle n’est plus gérée par le système  de fichiers sous /dev/shm celui-ci doit être diminué à 2 Go pour pouvoir accueillir uniquement l’instance ASM dont la mémoire est toujours gérée automatiquement et dynamiquement (AMM) dans la release 11.2.0.2. Cette modification nécessite un arrêt des instances Oracle et ASM, un démontage du FS, une réinitialisation de la taille du FS shmfs à 2048m dans le fichier de configuration /etc/fstab et un remontage de FS.

Configuration Oracle

Il est en général recommandé d’initialiser les paramètres SGA_TARGET et SGA_MAX_SIZE à des valeurs identiques et ces valeurs doivent être un multiple de la granularité mémoire de la SGA qui est de 256 Mo dans notre cas (v$sgainfo  Granule Size). Pour l’utilisation des Hugepages Oracle recommande d’initialiser explicitement les paramètres de l’instance MEMORY_TARGET et MEMORY_MAX_TARGET à zéro ou désactivés.

Depuis la release 11.2.0.2 un nouveau paramètre a été introduit pour l’utilisation des Hugepages par l’instance de la base de données : USE_LARGE_PAGES. Ce paramètre peut être initialisé à 3 valeurs possibles : TRUE, ONLY, FALSE et AUTO (avec le patchset 11.2.0.3).

En fonction de la valeur associée à ce paramètre des différences sont à noter quant au démarrage de l’instance ainsi :

• TRUE: C’est la valeur par défaut, le comportement normal au démarrage de l’instance est d’utiliser les Hugespages si celles-ci sont configurées sur le système.
  • En 11.2.0.2 si les hugepages sont insuffisantes pour démarrer l’instance alors les pages standard ‘mémoire’ du système seront allouées
  • En 11.2.0.3 le comportement est mixte au démarrage de l’instance Oracle attribuera la mémoire à hauteur des hugepages disponibles et le reste de la mémoire sera alloué aux pages standards du système.
• ONLY : L’instance ne démarre pas si les hugepages ne peuvent pas contenir la totalité de la mémoire demandée par la SGA.
• FALSE : Pas d’utilisation des Hugepages
• AUTO : Uniquement en 11.2.0.3 cette nouvelle option tente de reconfigurer le noyau Linux en augmentant le nombre de hugepages. Cette option ne change pas la valeur du nombre de hugepages définie dans le fichier /etc/sysctl.conf

alter system reset MEMORY_TARGET scope=spfile sid='*';
alter system reset MEMORY_MAX_TARGET scope=spfile sid='*';
alter system set USE_LARGE_PAGES='ONLY' scope=spfile sid='*';
alter system set SGA_MAX_SIZE=64g scope=spfile sid='*';
alter system set SGA_TARGET=64g scope=spfile sid='*';
shutdown immediate;
startup;

Vérification de l’utilisation des Hugepages

Une fois l’instance redémarrée, nous pouvons vérifier si les HugePages sont utilisées avec la commande ci-dessous. Le nombre de pages disponibles doit être inférieur au nombre de pages configurées:

grep Huge /proc/meminfo

Les pages ne sont pas forcément encore toutes allouées mais elles peuvent être réservées. Pour vérifier les segments de mémoire partagés, nous pouvons également exécuter la commande ci-dessous :

ipcs -m

Les segments dans les HugePages sont généralement alloués avec les droits 600 alors que ceux dans la mémoire classique sont protégés par 660.

Voilà en espérant que ce petit article vous permette d’implémenter facilement les hugepages avec Oracle.