Sémaphore et mémoire partagée … kézako ?

Oracle utilise une zone de mémoire bien connue des DBA que l’on appelle la SGA (System Global Area). Cette zone de mémoire, divisée en pools spécialisés, est accessible à tous les processus Oracle (Background process, mais aussi process serveurs).

Cette zone mémoire est donc une zone de mémoire partagée. De ce caractère découle une problématique qui est celle de l’accès à des ressources disponibles à tous moments par plusieurs processus (en informatique, l’accès concurrent se fait un à un).

Cette caractéristique système se résout par un mécanisme système que l’on appelle sémaphore.

Le nom de Sémaphore a été hérité des mécanismes de chemins de fers qui servaient à indiquer si un train pouvait passer ou non sur une voie « partagée ».

Lors de la demande d’accès à une ressource partagée (une page mémoire), le processus interroge le sémaphore pour savoir si la page mémoire est verrouillée ou non. Si elle l’est, alors il attend. Si elle ne l’est pas, alors le process demande au sémaphore de « lever » le drapeau, puis il réalise son action sur la zone mémoire, et enfin demande de « baisser » le drapeau du sémaphore.

On peut donc demander à un sémaphore, trois opérations :
  Verrouiller (set)
  Déverrouiller (clear)
  Tester (test)

La mémoire partagée sur Oracle

Toute personne ayant déjà installé Oracle s’est vu confrontée à devoir définir des paramètres shm*. Ces paramètres règlent l’allocation de la mémoire partagée sur Oracle (shm = shared memory).

Ces paramètres sont au nombre de 4. Cependant avant de passer au détail de ces paramètres il faut savoir comment est allouée la mémoire partagée par Oracle.

Allocation de la mémoire partagée

L’allocation de la mémoire partagée se fait par segments au démarrage de l’instance. Au démarrage, le système essaie d’allouer la taille demandée en un segment, si elle ne dépasse pas une taille maximale de segment. Si ce n’est pas le cas, l’allocation sera faite de plusieurs segments. Dans un premier temps, le système essaiera de les allouer de manière contiguë, sinon les segments ne le seront pas.

La totalité de la mémoire partagée peut donc être constituée de plusieurs segments contigus ou non. Il est bien sur plus performant d’avoir des segments contigus, l’option optimale étant d’avoir un seul segment.

Les paramètres système vont donc définir le nombre maximum de ces segments, leur taille maximum etc.

Paramétrage

Le paramétrage système de la mémoire partagée se fait par 4 paramètres système principaux.

Contrôle de la mémoire partagée et de son allocation

Le contrôle de l’allocation des segments de mémoire partagée peut se faire :
 sans distinction d’appartenance à telle ou telle instance en utilisant la commande OS

 avec distinction de l’appartenance à une instance avec l’outil oracle « sysresv »

Note : la commande sysresv sert normalement à relâcher des segments de mémoire partagée. L’option –i permet de la rendre interactive et de visualiser les segments sans faire de catastrophe.

Détection des erreurs

Les erreurs de mémoire partagée Oracle ont lieu généralement lors de l’allocation des segments. Ces opérations interviennent lors du démarrage de l’instance dès le mode NOMOUNT.

Ces erreurs font généralement appel à des fonctions SHMM*. Un problème d’allocation de mémoire partagée peut être caractérisé par les ORA suivantes : ORA-27100, ORA-27102, ORA-27125, ORA-27123 pour les plus communes.

Les ORA 27100 à 27125 caractérisent généralement des problèmes de mémoire partagée, ils interviennent généralement au tout démarrage de l’instance et sont consignés dans l’alert.log.

Les sémaphores et leur gestion dans Oracle

Fonctionnement de la demande en sémaphore

En introduction, nous avons vu comment fonctionnaient les sémaphores. Au niveau de l’OS, un sémaphore n’est pas alloué à la volée, un par un, mais par groupe ou set de sémaphore. Lorsqu’une application (une instance Oracle par exemple) a besoin d’utiliser des sémaphores, elle va allouer un groupe de sémaphore.

Ce groupe sera constitué d’un certain nombre de sémaphore pouvant être utilisé pour les accès concurrents à la mémoire par plusieurs processus.

Dans la mesure ou l’accès concurrent est géré par processus (pour résumer : 1 sémaphore par processus), oracle essaie d’allouer un groupe de sémaphore contenant la valeur de 2 x PROCESSES sémaphores (depuis Oracle v8 : Oracle alloue toujours 2 x PROCESSES sémaphores au démarrage de l’instance puis en relâche la moitié dès que l’instance est démarrée.) . Si il n’y arrive pas, alors il essaie d’allouer ce même nombre de sémaphores dans plusieurs sets (dans une certaine limite). Si il n’y arrive toujours pas, alors l’instance ne démarre pas.

Note : La contenance d’un set en sémaphore peut évoluer le long de la vie de l’instance.

Paramétrage

Le paramétrage des sémaphores se réalise par plusieurs paramètres dont les plus importants sont :

Ces paramètres vont conditionner le nombre de sémaphores et le nombre de conteneurs de sémaphores.

Le nombre de sémaphore effectif sera équivalent à la plus petite valeur de (semmni * semmsl) et de semmns.

Contrôle des sémaphores

Le contrôle des sémaphores du système se fait également de deux manières, à deux portées différentes :

 Sans distinction d’appartenance à l’instance avec la commande système ipcs :

On y voit dans ce cas, 4 sets de sémaphores dont le propriétaire est Oracle contenant respectivement 44, 154, 154, et 154 sémaphores chacun.

 Avec distinction d’appartenance à l’instance avec la commande oracle sysresv :

Là encore, on peut corréler les informations d’allocations des sets de sémaphores et contrôler le nombre de sémaphore qu’utilise une instance (dans notre cas 154 sémaphore dans un jeu pour l’instance orcl ; le paramètre PROCESSES de cette instance étant à 150).

Détection d’erreurs

Comme pour la mémoire partagée, les erreurs concernant les sémaphores se produisent très souvent au démarrage de l’instance.

Les messages d’erreurs détectés sont généralement les suivants : ORA-7250, ORA-7279, ORA-7251, ORA-7252, ORA-7339.

Ces messages d’erreurs sont toujours consignés dans l’alert.log de l’instance.

Notes supplémentaires

Les segments de mémoire partagée en Solaris 10

Solaris 10 gère la mémoire partagée et son allocation de manière dynamique. Ainsi, il n’est plus nécessaire de rebooter les serveurs dès que l’on modifie la configuration des paramètres shm.

Cette gestion se fait maintenant par l’intermédiaire de projets utilisateurs : on définit un projet pour l’utilisateur Oracle pour lequel on définit ses besoins en mémoire partagée.

Dans la documentation officielle oracle d’installation, oracle met en correspondance les anciens paramètres avec les nouvelles dénominations dans le cadre de projets Solaris 10.

Or, l’équivalence des noms n’est pas l’équivalence des fonctions. En effet, le paramètre shmmax (qui règle la taille d’un segment de mémoire partagée) ne trouve plus son équivalent dans le paramètre project.max-shm-memory (comme indiqué dans la doc officielle).

En effet, ce paramètre définit la valeur maximale de mémoire partagée utilisable par tout le projet utilisateur … donc pour TOUTES les instances démarrées sous ce compte.

Il faut donc adapter ce paramètre qui ne définit plus la taille maximale d’un segment de mémoire partagée mais la taille de la mémoire partagée (ie. somme de toutes les SGA) utilisée par ce projet.

Sous AIX et TRU64 UNIX

Sous ces deux OS, on ne configure pas de sémaphores. AIX et TRU64 Unix utilisent d’autres mécanismes internes pour la gestion des accès concurrents à la mémoire.

Relâcher des ressources non remises au système

Quelquefois, une défaillance d’instance ne va pas libérer les segments de mémoire partagée. Ainsi lorsqu’on redémarre l’instance, on se retrouve confronté à des messages d’erreurs concernant la mémoire partagée : SHM*, ou le système nous dit que l’instance est déjà démarrée alors qu’au processus background n’existe.

Dans ce cas, il est possible que la mémoire partagée n’ait pas été libérée après le crash d’instance.

Pour cela, on utilise l’utilitaire sysresv qui permet d’identifier un segment de mémoire partagée pour une instance donnée, puis avec la commande système « ipcrm », on libère le segment de mémoire :

Et sous Windows ??

Windows gère une instance Oracle différemment. En effet, sous UNIX, une instance Oracle est gérée par des processus lourd (espace de pile propre, espace de mémoire propre), ce qui nécessite une mémoire typique : la mémoire partagée pour les échanges de données entre les processus et des sémaphores pour la priorité d’accès à cette mémoire.

Sous Windows, nous avons un seul processus (Oracle.exe) dans lequel les équivalents des processus unix sont représentés par des Thread système (donc invisible si on ne dispose pas des ressources kits nécessaires).

La mémoire est donc allouée pour un processus et l’accès concurrent à la mémoire est géré de manière interne au processus par des exclusions mutuelles généralement gérées par des MUTEX. Il n’y a donc pas de mémoire partagées et donc rien à configurer de ce coté.