Solaris mon amour

Petit sujet qui m'a tenu en haleine. Pour faciliter sa compréhension je le découpe en deux parties : une première partie sur un problème d'initialisation d'un segment de type ISM et une seconde partie sur un dysfonctionnement de l'ISM. Les deux sous Solaris x86 uniquement.

Mais de quoi parlons nous ? Quelques explications sont nécessaires. Pour partager des données et synchroniser des évènements entre processus, le système Solaris utilise un framework nommé IPC (InterProcess Communication). Ce framework contient plusieurs objets IPC dont le standard POSIX IPC : POSIX semaphores, POSIX shared memory et POSIX message queues. 

J'évoque ici l'objet IPC : POSIX shared memory. Cet objet est notamment utilisé dans les bases de données (en tout cas Oracle et Sybase). Pour les "spécialistes" de ces produits, il s'agit ni plus ni moins de la fameuse SGA. Pour nous, les "spécialistes" du système nous appelons cela un segment SHM (Segment sHared Memory). Lors du démarrage d'une instance Sybase ou Oracle, un segment SHM est initialisé avec une taille spécifique. Si cette taille n'est pas disponible, l'instance ne s'active pas. 

Par défaut, la création d'un segment SHM : 

• n'est pas locké en mémoire (donc swappable).
• utilise des tailles de pages par défaut (soit 4K sous Solaris x86 et 8K sous Solaris sparc).
• n'utilise pas de table de translation d'addresse commune entre tous les processus utilisants ce segment.

Les ingénieurs Solaris ont donc optimisé la gestion de ce segment SHM : ISM (Intimate Shared Memory).

L'ISM corrige les problèmatique d'un segment SHM classique : 

• taille de pages optimisée.
• création d'une table de partage d'adresse pour optimiser les translation.
• segment automatiquement locké en mémoire.

L'utilisation de ce type de segment est devenu le standard pour les bases de données : la SGA fonctionne donc avec un segment ISM sous Solaris.

D'où mon problème : ma base de données Oracle 11g r2 sous Solaris 10x86 (update 9) n'utilise pas un segment ISM mais un simple segment SHM !!! Analysons un peu tout cela. 

En espectant l'espace d'adresse du process Oracle (ici pmon), j'ai étais surpris de constater que la SGA utilisait un segment SHM classique : 

# pmap -x 10735
10735:  ora_pmon_XXXX22
         Address   Kbytes       RSS    Anon   Locked Mode   Mapped File
0000000000400000   222240     91144       -       - r-x--   oracle
000000000DD17000     1180       676     208       - rw---   oracle
000000000DE3E000      136        32      32       - rw---   oracle
000000000DE60000     1828      1644    1632       - rw---   [ heap ]
0000000060000000        4         4       -       - r--s-   [ shmid=0x4000003c ]
0000000060001000  2097156   2028692       -       - rwxs-   [ shmid=0x4000003c ]
FFFFFD7FFCAA0000       64         8       8       - rwx--   [ anon ]
FFFFFD7FFCABE000       72         8       8       - rw---   [ anon ]
FFFFFD7FFCAD0000       64        12      12       - rw---   [ anon ]
[...] 

L'initialisation d'un segment type ISM provient du demandeur et non du système. J'ai donc décidé de vérifier les logs de démarrage de l'instance Oracle (fichier alert.log). Je suis tombé sur ce message fort intéressant : 

Mon Nov 21 16:38:40 2011
Starting ORACLE instance (normal)
WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x0000000080002000 [flag=0x4000] 

Lors de l'activation de l'instance, Oracle a tenté d'activer un segment type ISM sans y être parvenu. Le message indiquant l'erreur suivante : Not enough physical memory for SHM_SHARE_MMU segment. Tiens donc pas assez de mémoire ? Alors que la SGA demandée correspondait à seulement 2 Go ? La vérité était ailleurs... 

Pour mieux reproduire le problème, j'ai décidé d'écrire un petit programme C me permettant de créer un segment type ISM. Contrairement à ce que je pensais, ce n'est pas lors de la création du segment que le type ISM est spécifié mais lors d'un attachement. 

La création et l'attachement correspondent aux appels suivants :

shmget(2, size, 0660 | IPC_CREAT | IPC_EXCL)

shmat(shmid, (void *)0, SHM_SHARE_MMU) 

Le flag SHM_SHARE_MMU de la fonction shmat permet l'utilisation de l'ISM. L'exécution de mon petit programme C m'a permis d'activer sans problème un segment ISM de 10 Go. 

# ./ishm
shmid: 1526726689

# ipcs -m
IPC status from <running system> as of Tue Jan 10 11:26:10 CET 2012
T         ID      KEY        MODE        OWNER    GROUP
Shared Memory:
m 1526726689   0x2        --rw-rw----     root     root

[...]

# pmap -x 24680
24680:  ./ishm
         Address   Kbytes       RSS  Anon    Locked Mode   Mapped File
0000000000400000        4         4     -         - r-x--  ishm
0000000000410000        8         8     8         - rw---  ishm
FFFFFD7F80000000  1048576   1048576     -   1048576 rwxsR  [ ism shmid=0x5b000021 ]
FFFFFD7FFF210000       64        64    64         - rwx--  [ anon ]
FFFFFD7FFF230000       24        12    12         - rwx--  [ anon ]
FFFFFD7FFF240000     1276       712     -         - r-x--  libc.so.1
FFFFFD7FFF380000        4         4     4         - rwx--  [ anon ]
FFFFFD7FFF38F000       36        36    36         - rw---  libc.so.1
FFFFFD7FFF398000       16         4     4         - rw---  libc.so.1
FFFFFD7FFF3AE000      244       244     -         - r-x--  ld.so.1
FFFFFD7FFF3F0000        4         4     4         - rwx--  [ anon ]
FFFFFD7FFF3FB000        8         8     8         - rwx--  ld.so.1
FFFFFD7FFF3FD000        8         8     8         - rwx--  ld.so.1
FFFFFD7FFFDFE000        8         8     8         - rw---  [ stack ]
---------------- -------- --------- ----- ---------
        total Kb  1050280   1049692   156   1048576 

Mais où était mon problème ? Oracle doit en faire un peu plus ? J'ai donc tracé les appels systèmes lors du démarrage d'une instance. 

[...]
6362:   shmget(672617948, 1073754112, 0660|IPC_CREAT|IPC_EXCL) = 83886086
6362:   shmget(672617949, 0, 0)                         Err#2 ENOENT
6362:   shmget(672617950, 0, 0)                         Err#2 ENOENT
6362:   shmget(672617951, 0, 0)                         Err#2 ENOENT
6362:   shmat(83886086, 0x60000000, 040000)             Err#22 EINVAL
6362:   shmat(83886086, 0x60000000, 0)                  = 0x60000000
[...]

Oracle s'attache en spécifiant une adresse mémoire 0x60000000. J'ai donc modifié mon petit programme C en spécifiant la même adresse d'attachement et j'ai obtenu à ma grande surprise l'erreur suivante : 

# ./ishm
shmat: Invalid argument

J'ai obtenu la même erreur que le démarrage de la base Oracle. Bingo ! Lors de l'appel à la fonction shmat (si on spécifie l'adresse 0x60000000) l'attachement ne s'effectue pas. Mais pourquoi ? Dépassant un peu mes compétances j'ai ouvert un call au support Oracle. 

Réponse du support Oracle : la valeur 0x60000000 n'est pas divisible (valeur entière) par l'ensemble des tailles de pages disponibles sur le système Solaris 10x86. Il faut donc désactiver la taille de pages posant problème (option désactivée dans le kernel patch suivant 144489-17). Le workaround n'est pas applicable en production (boot en mode kernel debugging + modification avant chargement du kernel de la valeur largepagesupport). 

En vérifiant mes tailles de pages disponibles sur mon serveur DL380 G7, j'obtiens le résultat suivant : 

# pagesize -a
4096
2097152
1073741824 

Tiens donc, on peut utiliser des tailles de pages de 1Go !? Et bizarrement c'est avec cette taille de pages où la valeur 0x60000000 n'est pas divisible en une valeur entière. L'application du patch supprime la possibilité d'utiliser cette taille de pages. 

Voilà donc la fin de la 1er partie sur ISM et Solaris 10x86. La 2ème partie fait référence à un bug dans la gestion de l'ISM uniquement pour Solaris 10x86 (et Solaris 11x86). Bug que j'ai eu le privilège de découvrir en exclusivité... 

Ci-joint quelques références sur ce sujet : 

• Chapitre 4 "Interprocess Communication" dans Solaris internals 
• Shared memory uncovered par Jim Mauro
• Operating systems are lazy allocating memory par Tanel Poder
• Optimizing Applications with large working sets

Le 15 décembre dernier, lors de la commission "Unix vs Linux" organisée par l'AUFO, je suis intervenu (au nom du GUSES et d'ORNESS) pour développer le sujet suivant : Pourquoi choisir Solaris ?

Que retenir de cette commission ? Les témoignages utilisateurs indiquent une forte progression des migrations des environnements Unix (notamment HP-UX) vers Linux (notamment RedHat mais aussi Oracle Linux). Cependant dès qu'il s'agit d'adresser des problèmatiques de performances et de haute disponibilité, Solaris reste le système d'exploitation utilisé. Les personnes définissent à tort ou à raison l'association suivante : entrée de gamme Linux, milieu de gamme Linux ou Solaris, haut de gamme Solaris.

Solaris (tout comme Linux dans certaines mesures) est capable d'adresser toutes ces gammes en apportant plusieurs améliorations. D'abord, Solaris est aussi bien disponible sur plate-forme x86-x64 que sur plate-forme sparc. Ensuite, la gestion optimisée de la mémoire permet d'obtenir des gains notables notamment sur l'interaction avec les bases de données. Enfin, les outils de diagnostics disponibles (dont Dtrace) permettent d'analyser facilement tous les incidents qui survient sur le système.

J'ai été surpris de constater que plusieurs sociétés (petites ou grandes) commencent à utiliser Oracle Linux avec le noyau modifié d'Oracle (Unbreakable Linux). Ce noyau modifié affiche des performances bien supérieurs au noyau RedHat (à voir !?). Mais ce qui m'intéresse le plus dans ce noyau est l'inclusion des sondes Dtrace (enfin un outil de diagnostic correcte). Affaire à suivre.

Vous pouvez consulter ma présentation si vous le souhaitez.

Petite astuce sur une problématique connue par tous les administrateurs Solaris utilisants des baies du types CLX et VNX (baie clariion chez EMC) avec le gestionnaire de multipath natif de Solaris MPxIO.

En simplifiant grandement, lors de la première attribution de Lun(s) sur le serveur Solaris, le mécanisme de la baie utilise un type de lun spécifique appelé LUNZ. Il s'agit ni plus ni moins d'une lun d'administration qui à l'image des Gatekeeper sous DMX ne s'intégre pas à la configuration MPxIO du serveur (je ne détaille pas ici les raisons). Une fois l'attribution des luns effectuée sur le serveur, cette LUNZ est substituée par une lun classique. Mais voilà le probléme, la configuration MPxIO n'est plus correct. En effet la Lun qui reprend la position de la LUNZ n'est pas sous contrôle MPxIO. Le plus simple est de rebooter le serveur en mode reconfiguration mais en production ce n'est pas toujours possible.

Voilà donc la solution de ce petit problème que j'ai plaisir à répéter un peu trop souvent à mes collégues :)

# luxadm probe | more
No Network Array enclosures found in /dev/es

Found Fibre Channel device(s):
  Node WWN:50060160b9a01d49  Device Type:Disk device
    Logical Path:/dev/rdsk/c2t5006016839A01D49d0s2
    Logical Path:/dev/rdsk/c2t5006016039A01D49d0s2
    Logical Path:/dev/rdsk/c3t5006016A39A01D49d0s2
    Logical Path:/dev/rdsk/c3t5006016239A01D49d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900A477E76B20CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C041CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C241CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
    Logical Path:/dev/rdsk/c4t60060160FB112900C441CD7320CADF11d0s2
  Node WWN:50060160bb205594  Device Type:Disk device
...

La LUNZ prenant la première position, on nomme fréquemment ce dysfonctionnement de problème entre LUNZ et LUN0. 

# fcinfo hba-port
HBA Port WWN: 10000000c99920a4
        OS Device Name: /dev/cfg/c3
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.11a5 (U3D1.11A5)
        FCode/BIOS Version: Boot:5.03a4 Fcode:3.10a3
        Serial Number: 0999BT0-10380003HU
        Driver Name: emlxs
        Driver Version: 2.50o (2010.01.08.09.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 4Gb
        Node WWN: 20000000c99920a4
HBA Port WWN: 10000000c9991aae
        OS Device Name: /dev/cfg/c2
        Manufacturer: Emulex
        Model: LPe12000-S
        Firmware Version: 1.11a5 (U3D1.11A5)
        FCode/BIOS Version: Boot:5.03a4 Fcode:3.10a3
        Serial Number: 0999BT0-10380003EC
        Driver Name: emlxs
        Driver Version: 2.50o (2010.01.08.09.45)
        Type: N-port
        State: online
        Supported Speeds: 2Gb 4Gb 8Gb
        Current Speed: 4Gb
        Node WWN: 20000000c9991aae

# fcinfo remote-port -p 10000000c99920a4 -s
Remote Port WWN: 5006016a39a01d49
        Active FC4 Types: SCSI
        SCSI Target: yes
        Node WWN: 50060160b9a01d49
        LUN: 0
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c3t5006016A39A01D49d0s2
        LUN: 1
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00E0BF020FE0A5DF11d0s2
        LUN: 2
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00B827016B604BDE11d0s2
        LUN: 3
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00347A5E80604BDE11d0s2
... 

Il suffit simplement de déconfigurer tous les paths de cette Lun et de la redécouvrir. Attention tout de même qu'aucune ressource utilise l'in des paths de cette Lun, par exemple : des datas, dans la configuration d'un gestionnaire de volumes, un agent type Navisphere, etc.

# luxadm -e offline /dev/rdsk/c2t5006016839A01D49d0s2
devctl: I/O error

# vxdisk -e list | grep -i 5006016039A01D49d0
c2t5006016039A01D49d0s2 auto:sliced - - online c2t5006016039A01D49d0s2

# vxdisk rm c2t5006016039A01D49d0s2 

# luxadm -e offline /dev/rdsk/c2t5006016839A01D49d0s2
# luxadm -e offline /dev/rdsk/c2t5006016039A01D49d0s2
# luxadm -e offline /dev/rdsk/c3t5006016A39A01D49d0s2
# luxadm -e offline /dev/rdsk/c3t5006016239A01D49d0s2

# cfgadm -al
...
c2                             fc-fabric    connected    configured   unknown
c2::5006016039a01d49           disk         connected    configured   unusable
c2::500601603b205594           disk         connected    configured   unknown
c2::500601603b206f30           disk         connected    configured   unknown
c2::5006016230603a09           disk         connected    configured   unknown
c2::5006016839a01d49           disk         connected    configured   unusable
c2::500601683b205594           disk         connected    configured   unknown
c2::500601683b206f30           disk         connected    configured   unknown
c2::5006016a30603a09           disk         connected    configured   unknown
c3                             fc-fabric    connected    configured   unknown
c3::5006016130603a09           disk         connected    configured   unknown
c3::5006016239a01d49           disk         connected    configured   unusable
c3::500601623b205594           disk         connected    configured   unknown
c3::500601623b206f30           disk         connected    configured   unknown
c3::5006016930603a09           disk         connected    configured   unknown
c3::5006016a39a01d49           disk         connected    configured   unusable
c3::5006016a3b205594           disk         connected    configured   unknown
c3::5006016a3b206f30           disk         connected    configured   unknown
... 

# cfgadm -o unusable_FCP_dev -c unconfigure c2::5006016039a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c2::5006016839a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c3::5006016239a01d49
# cfgadm -o unusable_FCP_dev -c unconfigure c3::5006016a39a01d49

La déconfiguration de cette Lun par ces quatres paths est terminée. Il suffit donc de la réintégrer au serveur.

# cfgadm -c configure c2::5006016039a01d49
# cfgadm -c configure c2::5006016839a01d49
# cfgadm -c configure c3::5006016239a01d49
# cfgadm -c configure c3::5006016a39a01d49

# devfsadm -Cv
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016839A01D49d0s3
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016239A01D49d0s6
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016A39A01D49d0s5
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016039A01D49d0s2
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016A39A01D49d0s2
devfsadm[25244]: verbose: removing file: /dev/rdsk/c2t5006016039A01D49d0s5
devfsadm[25244]: verbose: removing file: /dev/rdsk/c3t5006016239A01D49d0s1
... 

Une petite vérification simpose toujours.

# fcinfo remote-port -p 10000000c99920a4 -s
Remote Port WWN: 5006016a39a01d49
        Active FC4 Types: SCSI
        SCSI Target: yes
        Node WWN: 50060160b9a01d49
        LUN: 0
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
        LUN: 1
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00E0BF020FE0A5DF11d0s2
        LUN: 2
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00B827016B604BDE11d0s2
        LUN: 3
          Vendor: DGC
          Product: RAID 5
          OS Device Name: /dev/rdsk/c4t600601600C421C00347A5E80604BDE11d0s2
...

# luxadm disp /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
  Vendor:               DGC
  Product ID:           RAID 5
  Revision:             0326
  Serial Num:           CK200070200964
  Unformatted capacity: 34818.750 MBytes
  Read Cache:           Enabled
    Minimum prefetch:   0x0
    Maximum prefetch:   0x0
  Device Type:          Disk device
  Path(s):

  /dev/rdsk/c4t600601600C421C00CA9ECD0544A5DF11d0s2
  /devices/scsi_vhci/ssd@g600601600c421c00ca9ecd0544a5df11:c,raw
   Controller           /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016039a01d49,0
    Host controller port WWN    10000000c9991aae
    Class                       secondary
    State                       ONLINE
   Controller           /devices/pci@1,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016839a01d49,0
    Host controller port WWN    10000000c9991aae
    Class                       primary
    State                       ONLINE
   Controller           /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016239a01d49,0
    Host controller port WWN    10000000c99920a4
    Class                       secondary
    State                       ONLINE
   Controller           /devices/pci@11,700000/SUNW,emlxs@0/fp@0,0
    Device Address              5006016a39a01d49,0
    Host controller port WWN    10000000c99920a4
    Class                       primary
    State                       ONLINE

Et voilà rien de plus facile. Quelques commandes dans un autre bien précis pour corriger un dysfonctionnement de MPxIO avec ce type de baie. Juste une dernière précision, si vous retirez cette Lun (en position 0), lors d'un prochain ajout il est possible que vous retombiez sur ce cas de figure. Mais bon vous avez l'astuce maintenant.