Sybase et troubleshooting de la mémoire partagée

Logo

Introduction

Des problèmes critiques peuvent survenir sur les allocations de mémoire partagée et de sémaphores par Sybase ASE, notamment lorsque ce dernier est tué violemment par la commande kill Unix, ce qui peut engendrer notamment le verrouillage du port. L’objectif de cette note technique est de montrer comment ne pas arriver à la solution extrême du redémarrage du système OS Unix grâce à l’utilisation des commandes ipcs, ipcrm et lsof.

Erreurs Sybase ASE liées à l’allocation de mémoire partagée (Shared Memory)

Adaptive Server utilise les fonctions ci-dessous pour gérer la mémoire partagée :

  • os_get_shmid : créé un identifiant de mémoire partagée
  • os_create_region : créé une région de mémoire partagée avec un identifiant
  • os_attach_region : attache une région de mémoire partagée au serveur ASE
  • os_detach_region : détache du serveur ASE et supprime la région de mémoire partagée
  • os_format_shmid : formatte la mémoire partagée correspondant à un identifiant

Lorsqu’une erreur se produit dans l’appel de la fonction os_create_region, Sybase ASE ne peut démarrer.

Sur les environnements Unix, les messages associés à une erreur qui se produit dans l’appel de la fonction os_create_region sont listés ci-dessous :

Message Signification
os_create_region: shmget (0x%x): %s Ce message est écrit dans le fichier de log lorsqu’Adaptive Server n’est pas en mesure d’acquérir un segment de mémoire partagée (shared memory segment). %x est une clé de mémoire partagée basée sur l’identifiant de mémoire partagée et %s est un message de l’OS.
os_create_region: Shared memory segment %d is in the way Cette erreur se produit après le message shmget ci-dessus et est également écrit dans le fichier de log. Lorsque %d vaut –1, cela signifie que la région n’existe pas.
os_create_region: uninitialized shared memory descriptor Durant la création de la région de mémoire partagée, Adaptive Server tente de valider le descripteur de la région de mémoire. Ce message est écrit dans le fichier de log si le descripteur trouvé est invalide.
os_create_region: shmat (%d): %s Ce message est écrit dans le fichier de log lorsque ASE échoue dans l’attachement. Dans ce message, %d est l’identifiant de la mémoire partagée et %s est un message de l’OS.
os_create_region: can't allocate %d bytes Adaptive Server n’a pas été en mesure d’acquérir le nombre %d de bytes demandé dans la région de la mémoire partagée.

Cas du port gelé par un serveur Sybase

Dans le cas pratique exposé dans cette note technique, le port d’un serveur Sybase est gelé et la shared memory n’est pas relâché.

Prérequis sur l’utilisation du binaire lsof

Le binaire lsof n’est pas systématiquement installé sur un système et il est par défaut installé dans le répertoire /usr/local/bin.

Pour les système Solaris, le package lsof est disponible sur le site www.sunfreeware.com.

À titre d’illustration : pour SPARC, solaris 8, il suffit d’installer le package lsof 4.68 (lsof-4.68-sol8-sparc-local.gz) et pour effectuer l’installation :

% gunzip lsof-4.68-sol8-sparc-local.gz
% pkgadd –d lsof-4.68-sol8-sparc-local

Cas pratique d’une non relâche de la shared memory et du port Sybase

Dans le cas pratique de cette documentation, un serveur Sybase écoutant sur le port 30004 tombe violemment sans relâcher le port et la mémoire partagé associée.

Commande ipcs –a

La première opération consiste à visualiser les segments de mémoire partagée utilisée par Sybase avec la commande ipcs –a

% ipcs -a

IPC status from <running system> as of Mon Oct 18
11:44:56 MEST 2004

T ID KEY       MODE        OWNER  GROUP  CREATOR CGROUP NATTCH SEGSZ     CPID   LPID  ATIME
DTIME    CTIME
Shared Memory:

m 1  0x651f801d --rw------- sybase dba   sybase  dba    1      335896576 20696  20696 10:21:13
no-entry 10:21:11

m 2  0x651f8613 --rw------- sybase dba   sybase  dba    2      512696320 20768  20776 10:22:02
10:22:02 10:21:46

La commande ipcs –a permet de visualiser les PID et les clés des segments de mémoire partagée utilisés par Sybase.

Commande lsof –i

La commande lsof –i va quant à elle permettre de visualiser le port occupé 30004 et par quels PID :

% /usr/local/bin/lsof -i TCP | grep '30004'

dataserver 20768 sybase 257u IPv4 0x30009b33eb0 0t0  TCP SRVUNXFR47:30004 (LISTEN)
dataserver 20776 sybase 257u IPv4 0x30009b33eb0 0t0  TCP SRVUNXFR47:30004 (LISTEN)

Avec la commande lsof –i/, on voit nettement que le port 30004 est occupé par les PIDs 20768 et 20776, ce qui correspond à la clé 0X651f8613 dans le résultat de la commande ipcs –a.

Suppression de la mémoire partagée et relâche du port (ipcrm)

À l’issue des informations retournées par les commandes ipcs et lsof, la commande ipcrm va permettre d’effectivement supprimer la mémoire partagée et ainsi relâcher le port.

Avant toutefois de supprimer la mémoire partagée avec la commande ipcrm, les fichiers *.krg et *.mrg liés aux serveurs Sybase et Monitor Server doivent être supprimés manuellement.

La commande ipcrm peut à présent être utilisée :

ipcrm [-m shmid] [-q msqid] [-s semid] [-M shmkey]
       [-Q msgkey] [-S semkey]

dans la syntaxe ipcrm :

  • -m shmid : supprime l’identifiant de mémoire partagée du système. Le segment de mémoire partagée et les structures de données associées sont détruites
  • -M shmkey : supprime l’identifiant de mémoire partagée du système créé avec la clé shmkey. Le segment de mémoire partagée et les structures de données associées sont détruites

Dans l’exemple pratique : deux syntaxes sont donc possibles pour supprimer effectivement le segment de mémoire partagée.

% ipcrm –m2
% ipcrm -M0x651f8613

Conclusion

À l’issue du lancement de l’analyse, il convient de verifier que le port est bien relâché et que la mémoire partagée est effectivement supprimée en réinitiant les commandes ipcs –a et lsof –i.