Jeudi 16 février 2012 4 16 /02 /Fév /2012 08:20

 

C'est une question que plusieurs d'entre nous (admistrateurs de base de données ou adminstrateurs systèmes) se posent. Quelques éléments de réponses évoqués dans cette article.

 

Pour rappel, il s'agit d'une option cachée dans la base de données Oracle (_enable_NUMA_support en Oracle 11g et _enable_numa_optimization en Oracle 10g). Cette option lorsqu'elle est activée permet de découper la mémoire partagée par les processus Oracle en plusieurs segments (la fameuse SGA). Cependant ce découpage dépend exclusivement de l'architecture matérielle sur laquelle la base Oracle s'exécute. En Oracle 10g jusqu'à la version 10.2.0.3, cette option était active par défaut. Bizarrement, cette option a été désactivé dans toutes les autres versions (encore actuellement avec la 11gr2). Pourtant, activer cette option peut s'avérer fort utile (voir le workaround concernant un bug dans l'ISM avec Solaris x86).

 

Que devons nous faire alors ? Si vous posez la question au support Oracle bases de données la réponse est clair : ne pas l'activer. Par contre si vous posez la question su support Oracle système la réponse est légérement différente : oui vous pouvez l'activer si votre architecture est NUMA. Cette option active par défaut dans les versions inférieurs à la 10.2.0.4 pose plusieurs problèmes si la base de données s'exécute sur une architecture non NUMA (bizarrement, c'est ce qu'il s'est notamment produit avec les serveurs HP Superdome). Suite à plusieurs incidents remontés au support Oracle bases de données, les équipes de dev ont tout simplement décidé de désactiver cette option (bien avant le rachat de Sun par Oracle).

 

Pour répondre à un besoin particulier, nous avons décidé de l'activer sur plusieurs bases de données. Pour le moment aucun disfonctionnement nous a été remonté vis-à-vis de la gestion de la mémoire partagée mais voilà ce que nous avons détecté lors de sa mise en place sur des serveurs Solaris 10u9... 

 

Lors du démarrage de la base de données, nous avons constatés les messages suivants dans le fichier d'alertes d'Oracle :

 

[...]
2012-01-20 14:52:17.564000 +01:00

WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:52:32.994000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:52:49.119000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:53:04.047000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
[...]   

 

Les différents segments ont tous été activés correctement ( 4 segments + 1 pour la gestion) :

 

# pmap -x 2993
[...]
0000000060000000 14024704 14024704 - 14024704 2M rwxsR [ism shmid=0x7000003]
00000003C0000000 11796480 11796480 - 11796480 2M rwxsR [ism shmid=0x7000004]
00000006A0000000 11796480 11796480 - 11796480 2M rwxsR [ism shmid=0x7000005]
0000000980000000 11927552 11927552 - 11927552 2M rwxsR [ism shmid=0x7000006]
0000000C60000000 11796480 11796480 - 11796480 2M rwxsR [ism shmid=0x7000007]
0000000F40000000       20       20 -       20 4K rwxsR [ism shmid=0x7000008]
[...] 

 

En traçant le démarrage de la base Oracle, on obtient les informations suivantes :

 

[...]
shmget(IPC_PRIVATE, 12079595520,0640|IPC_CREAT|IPC_EXCL) = 117440545

shmsys(5, 0x07000021, 0x00000001, 0xFFFFFC7FFFDFA2F8) = Err#22 EINVAL
[...] 

 

Le syscall shmsys() est uniquement utilisé lorsque l'option NUMA est activée dans la base. Le 1er argument de shmsys() permet de déterminer quelle sous fonction est exécutée. Il y a 4 choix possible et un par défaut. Etrangement le code retour du choix par défaut est EINVAL (code source). Pourquoi Oracle base de données utilise la valeur 5 pour cet argument ? S'agit'il d'un bug ? Pour info, l'erreur se produit autant de fois qu'il y a de segments.

 

Réponse du support Oracle : il s'agit d'un problème d'interfaçage entre Oracle bases de données et Solaris (bug 12596470). Ce bug est corrigé dans Solaris 10u10 et Solaris 11.

 

Malgré la présence de ce bug, l'activation de NUMA ne semble pas poser de problème. Les segments de la base de données utilisent les lgrps de Solaris. Mais les utilisent-ils correctement ?

 

En attendant un statut officiel d'Oracle sur l'activation ou non de cette option, vous pouvez tenter de l'activer au moins sur vos architectures de dev/test/uat avant de franchir le cap en production. Pour l'heure, plusieurs bases en production fonctionnent avec cette option active sans avoir eu de problème (à l'exception du bug cité ci-dessus).

 

 

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

 

Par gloumps - Publié dans : divers
Ecrire un commentaire - Voir les 0 commentaires

Dimanche 12 février 2012 7 12 /02 /Fév /2012 15:20

 

Après avoir rencontré quelques anomalies dans la gestion de ISM sous Solaris x86 (voir l'analyse du bug), nous allons étudier la manière de le contourner. Pour rappel le bug est le suivant : non partage de la table de pages en ISM. Les workarounds mis en oeuvre ici concernent uniquement les bases de données Oracle. Cependant certains d'entre eux peuvent vous aider à adresser ce type de problème dans contextes différents. Je remercie Alain et Thierry (consultants Oracle) pour l'aide apportée sur la mise en place de ces workarounds (notamment sur la partie Oracle base de données).

 

 

Ce bug a toujours existé dans Solaris 10x86, et pourtant personne ne l'a remarqué. Et pourquoi donc !? Il faut deux éléments pour qu'il devienne visisble sur le système :

  • Une taille de ISM importante (supérieur à 80 Go environ)
  • Une multitude d'attachements / détachements à cette ISM

 

Sans ces deux conditions, le dysfonctionnement n'est pas impactant pour le système (la consommation du serveur n'est pas affectée par des Spin locks provenant du bug). Il y a deux manières de controurner ce problème :

  • La taille de l'ISM
  • Diminuer le nombre d'attachements / détachements

 

Diminuer la taille de l'ISM va un peu à l'encontre de l'histoire !! Possédant des serveurs de plus en plus capacitifs (512 Go de RAM voir plus maintenant), et ne pas en profiter pleinement, c'est un peu ridicule. Une approche plus constructive serait de découper le segment ISM par plusieurs segments de plus petites tailles. Solaris a bien des qualités mais ne posséde malheuresement pas celle de découper un segment ISM (à l'inverse de Linux : voir shmmax et shmall).

 

Reste que le monde informatique est bien fait !! L'architecture des serveurs x86 (je parle des serveurs produits actuellement) fonctionne en utilisant le schéma mémoire NUMA. Pour simplifier, le temps d'accès à la mémoire dépend de sa localisation par rapport aux processeurs. Solaris utilise pleinement ces fonctionnalités à travers les locality groups (lgrp). La mémoire est implicitement découpée par le système Solaris. La base de données Oracle est capable de découper son segment de mémoire partagée sur les différents locality groups disponibles sur le serveurs. Quand je vous disais que le monde informatique était bien fait !! Il s'agit d'activer une option lors du démarrage de la base de données.

 

L'autre approche est de limiter le nombre d'attachements / détachements. Même si diminuer le nombre d'utilisateurs reste une solution, je ne vous la conseille pas !! Par contre utiliser les fonctionnalités d'Oracle base de données nous permet de répondre à ce besoin. Il s'agit d'utiliser soit la fonctionnalité de Shared Server soit la fonctionnalité de Database Resident Connection Pooling. La dernière fonctionnalité étant disponible en version 11g. 

 

Le protocol de tests est assez simple : lancement de 50 connexions simultanées (via sqlplus). Chaque sqlplus provoque une connexion / déconnexion à la base toutes les 2 secondes. L'activité du système est surveillée par la commande vmstat, les locks (et leurs temps) sont tracés avec un petit script Dtrace. Tous les tests ont été réalisés avec une SGA de 200 Go et 25 Go de shared pool.

 

Résultats obtenus :      

 

Cas 1 : Reproduction du problème

 

Paramétrage Aucun
Durée des 50 connexions 2m16s
Charge CPU Saturé en mode Système
Nombre de locks Spin et Block Des milliers de Spin et Block
Temps des locks Spin

Spin de quelques ms à 700ms

Temps des locks Block

Block de quelques ms à plusieurs milliers de ms

 

 

Cas 2 : Utilisation de NUMA

 

Paramétrage Activation de NUMA
Durée des 50 connexions 32s
Charge CPU 60% en mode système - 5% en mode user
Nombre des locks Spin et Block Des milliers de Spin et Block
Temps des locks Spin Spin inférieur à 1ms
Temps des locks Block Block compris entre 10ms et 100ms

 

Remarques :

  • 4 lgrps disponibles sur le serveur
  • 3 segments ISM de 50 Go + 1 segment ISM de 75 Go (50 Go de SGA et 25 Go PGA)
  • 1 segment ISM de quelques Mo pour la gestion des 4 autres segments

 

Cas 3 : Utilisation de Data Resident Connection Pooling dans Oracle

 

Paramétrage Activation du Data Resident Connection Pooling
Durée des 50 connexions 26s
Charge CPU Inférieur à 5% en mode système et user
Nombre des locks Spin et Block Quelques appels lors de la création des processus de pool
Temps des locks Spin Quelques nanosecondes
Temps des locks Block

Aucun

 

Remarques :

  • Lors du test, un hang non expliqué est apparu
  • Les limitations fonctionnelles de connexions au même schéma sont à valider par l'applicatif

 

Cas 4 : Utilisation de Shared Server      

 

Paramétrage Activation des Shared Server
Durée des 50 connexions 24s
Charge CPU Inférieur à 5% en mode système et user
Nombre des locks Spin et Block Quelques appels lors de la création des processus de pool
Temps des locks Spin Quelques nanosecondes
Temps des locks Block Aucun

 

Remarques :

  • Quelques ajustements à faire : nombre de serveurs, large pool, taille de la UGA
  • Fonctionnalités présentes depuis plusieurs versions d'Oracle base de données

 

Les 3 workarounds présentés ici permettent d'augementer la taille de la SGA de votre base Oracle sur Solaris x86 sans saturer votre système. Les fonctionnalités présentes dans Oracle (Data Resident Connection Pooling et Shared Servers) permettent même de masquer complétement le bug ISM : les attachements / détachements sont supprimés. Cependant leur mise en oeuvre nécessite un paramétrage à faire valider par les utilisateurs. L'option NUMA est plus simple à mettre en oeuvre mais dépend surtout de votre architecture matérielle : nombre de lgrps disponibles sur votre système (j'écris en ce moment un petit artcile à ce sujet).

 

 

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

 

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 0 commentaires

Mardi 31 janvier 2012 2 31 /01 /Jan /2012 23:03

 

Continuons un peu cette formidable aventure dans la gestion de l'ISM sous Solaris x86. Dans l'article précédent, j'évoque un problème d'initialisation de l'ISM provenant des tailles de pages. Dans cet article, j'ai découvert un bug dans la gestion de l'ISM toujours sous Solaris x86.

 

Suite à une migration d'une base de données Oracle d'une architecture Solaris Sparc à une architecture Solaris x86, l'équipe DBA a décidé d'utiliser pleinement la mémoire disponible sur cette nouvelle infrastructure. Disposant d'un serveur avec 512 Go de mémoire, la SGA de la base Oracle a été positionnée à 290 Go (afin de diminuer les lectures physiques et d'éviter les locks R/W). L'augmentation de cette SGA a eu un bénéfice important sur les opérations de lectures (plus d'activité sur les disques SAN concernant les lectures) par contre le système Solaris saturait...

 

# vmstat 3
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s6 s7 in sy cs us sy id
11 2 0 274157192 335523004 1348 8439 1506 2 2 0 1 5 -1 158 105 15844 31218 10183 5 7 88
2 12 0 86340852 144652404 1996 43583 0 25 24 0 0 0 0 0 0 64086 182685 44871 13 34 53
2 0 0 86352032 144645428 4773 45640 0 17 17 0 0 0 0 0 0 179020 200275 59466 16 31 53
0 1 0 86327500 144637200 1680 42171 0 35 33 0 0 0 0 0 0 69311 178558 44632 14 40 46
2 0 0 86357008 144655832 2035 35481 0 13 13 0 0 0 0 0 0 62857 162021 45164 13 25 63
2 0 0 86334148 144631452 1940 44848 0 11 11 0 0 0 0 0 0 64294 188696 43993 13 38 49
1 1 0 86171376 144496048 3014 52949 0 5 5 0 0 0 0 0 0 64821 192942 46708 17 30 52
52 1 0 86025360 144381188 1779 38176 0 16 16 0 0 0 0 0 0 47234 129932 29021 13 64 24
2 0 0 85953152 144301940 1766 50384 0 21 20 0 0 5 0 0 0 68138 181369 40882 18 46 37
0 2 0 86124088 144497016 2889 38238 0 11 11 0 0 0 0 0 0 53142 151981 36137 11 46 43
50 0 0 86065384 144470520 1806 46570 0 27 24 0 0 0 0 0 0 41055 147273 26207 9 71 20
2 0 0 86020672 144434312 1818 30717 8 3 1 0 0 0 0 0 0 59711 155183 37919 11 55 33
20 1 0 86000472 144415592 2892 46429 0 24 23 0 0 0 0 0 0 48937 161600 32703 12 66 23

^C

 

Le système saturait complètement lors de l'utilisation massive de la base de données. Avec un load de plus 200 sur 5 minutes, un pourcentage de 80 pour le SYS et 20 pour le USER, quelques choses ne fonctionnait pas correctement.

 

Passons à l'analyse de ce problème. D'abord, qui utilise le temps système ?

 

# dtrace -n 'profile-1001hz /arg0/ { @[execname] = count(); }'
dtrace: description 'profile-1001hz ' matched 1 probe
^C
[…]
mpathadm 1102
fsflush 2160
tnslsnr 4541
sched 37200
oracle 496331

 

Le temps système provient des process Oracle DB. Une bonne chose mais cela reste étrange. Que fait Oracle pour consommer autant de temps système ?

 

# dtrace -n 'profile-1001hz /arg0 && execname == "oracle" / { @[stack()] = count(); } tick-60s { trunc(@,5); exit(0);}'
dtrace: description 'profile-1001hz ' matched 2 probes
CPU ID FUNCTION:NAME
19 73222 :tick-60s

unix`mutex_delay_default+0x7
unix`mutex_vector_enter+0x99
ipc`ipc_get+0x62
shmsys`shmget+0x4a
shmsys`shmsys+0x7e
unix`sys_syscall+0x17b
83649

unix`mutex_delay_default+0xa
unix`mutex_vector_enter+0x99
ipc`ipc_lock_internal+0x4b
ipc`ipc_lock+0x11
shmsys`shm_detach+0x5c
shmsys`shmdt+0x90
shmsys`shmsys+0x6d
unix`sys_syscall+0x17b
94488

unix`mutex_delay_default+0x7
unix`mutex_vector_enter+0x99
ipc`ipc_lock_internal+0x4b
ipc`ipc_lock+0x11
shmsys`shm_detach+0x5c
shmsys`shmdt+0x90
shmsys`shmsys+0x6d
unix`sys_syscall+0x17b
108405

unix`mutex_delay_default+0xa
unix`mutex_vector_enter+0x99
ipc`ipc_lock_internal+0x4b
ipc`ipc_lookup+0x29
shmsys`shmat+0x70
shmsys`shmsys+0x59
unix`sys_syscall+0x17b
129651

unix`mutex_delay_default+0x7
unix`mutex_vector_enter+0x99
ipc`ipc_lock_internal+0x4b
ipc`ipc_lookup+0x29
shmsys`shmat+0x70
shmsys`shmsys+0x59
unix`sys_syscall+0x17b
147262

Fort intéressant !? Lors des appels systèmes shmat() et shmdt(), le système consomme son temps dans des mutex. Regardons cela de plus près. S'aggissant de locks type adaptive mutex, deux choses sont à vérifier : 

  • le temps d'acquisition de la ressource (cpu off donc mutex adaptive block)
  • le temps écoulé pendant l'obtention de la ressource (cpu on donc mutex spin)

 

J'ai écrit rapidement un petit script Dtrace me permettant de quantifier rapidement ces deux temps (j'utilise notamment la probe lockstat). Ci-joint le résultat

 

# ./ipc_lock.d

558462664068813 cpu  4 exec oracle pid 23796: adaptive-block(0) took 1015 ms
558461944173547 cpu 28 exe oracle pid 23864: adaptive-block(0) took 1185 ms
558462329451173 cpu 30 exe oracle pid 23886: adaptive-spin(0) took 2570 ms
558462329430767 cpu 31 exe oracle pid 23724: adaptive-spin(0) took 1930 ms
558463436775114 cpu  0 exec oracle pid 23906: adaptive-spin(0) took 1963 ms
558463900687630 cpu  0 exec oracle pid 22498: adaptive-spin(0) took 1598 ms
558463900815833 cpu  0 exec oracle pid 23165: adaptive-block(0) took 1088 ms
558463119973512 cpu  1 exec oracle pid 23840: adaptive-spin(0) took 2979 ms
558463900250335 cpu  2 exec oracle pid 23868: adaptive-spin(0) took 3515 ms
558463436925731 cpu  5 exec oracle pid 23786: adaptive-block(0) took 1397 ms
558463900448070 cpu  6 exec oracle pid 23808: adaptive-block(0) took 1199 ms
558463900426025 cpu 10 exec oracle pid 22343: adaptive-spin(0) took 1766 ms
558463436944972 cpu 14 exec oracle pid 23881: adaptive-block(0) took 1203 ms
558463775141403 cpu 15 exec oracle pid 23903: adaptive-spin(0) took 3979 ms
558463646477100 cpu 16 exec oracle pid 23858: adaptive-spin(0) took 3374 ms
558463545080417 cpu 17 exec oracle pid 23842: adaptive-block(0) took 1299 ms
558463775195434 cpu 20 exec oracle pid 23838: adaptive-block(0) took 1164 ms
558463775112272 cpu 21 exec oracle pid 23900: adaptive-spin(0) took 1893 ms
558464220990762 cpu  8 exec oracle pid 23471: adaptive-spin(0) took 1754 ms
558464221051681 cpu 15 exec oracle pid 23136: adaptive-spin(0) took 1967 ms
558466485966584 cpu  9 exec oracle pid 23903: adaptive-spin(0) took 1040 ms
558466153296593 cpu 16 exec oracle pid 23918: adaptive-spin(0) took 1597 ms
558467238545528 cpu  1 exec oracle pid 23855: adaptive-spin(0) took 1206 ms
558467660401004 cpu  8 exec oracle pid 23888: adaptive-spin(0) took 1917 ms
558466980614425 cpu  9 exec oracle pid 23938: adaptive-block(0) took 1141 ms
558466980595351 cpu 11 exec oracle pid 23930: adaptive-block(0) took 1354 ms
558467779687829 cpu 14 exec oracle pid 23955: adaptive-spin(0) took 2318 ms
558467976549814 cpu  4 exec oracle pid 23908: adaptive-spin(0) took 1210 ms
558467976490096 cpu  5 exec oracle pid 23641: adaptive-spin(0) took 1278 ms
558469750980230 cpu  3 exec oracle pid 23936: adaptive-spin(0) took 3297 ms
558469308862236 cpu  5 exec oracle pid 23911: adaptive-spin(0) took 1332 ms
558469308776939 cpu  7 exec oracle pid 23920: adaptive-spin(0) took 3390 ms
558469308793235 cpu  8 exec oracle pid 23890: adaptive-spin(0) took 3219 ms
558469308812116 cpu 10 exec oracle pid 23955: adaptive-spin(0) took 1413 ms
ˆC
558469750890183 cpu 11 exec oracle pid 23991: adaptive-spin(0) took 1774 ms

 

Ca se passe de commentaire non !? Plus de 3 secondes en moyenne pour les adaptive spin !!! Mais que se passe t'il exactement ? Lors de chaque attachement ou détachement à la SGA, le système lock la ressource IPC. En moyenne, il y a environ 20 attachements / détachements seconde sur cette base de données avec plus de 1000 connexions actives en simultanées (voir la colonne NATTCH).

 

# ipcs -mopi -z zonexxxx
IPC status from <running system> as of Tue Oct 23 10:14:51 CET 2011
T         ID      KEY        MODE        OWNER    GROUP NATTCH  CPID  LPID ISMATTCH
Shared Memory:
m  520093698   0x77adb4f8 --rw-rw----   oracle      dba   1338 29340 18826     1338    

 

Voyons un peu plus dans le détail les différentes stack() kernel obtenus lors des locks adaptive spin et block.

 

# ./ipc_stack.d

   unix`htable_release+0x93
   unix`hati_load_common+0x12d
   unix`hat_share+0x281
   genunix`segspt_shmattach+0xd2
   genunix`as_map_locked+0x102
   genunix`as_map+0x4a
   shmsys`shmat+0x500
   shmsys`shmsys+0x59
   genunix`dtrace_systrace_syscall+0xc7
   unix`sys_syscall+0x17b
   225

 

   unix`htable_lookup+0x8c
   unix`hati_load_common+0x5b
   unix`hat_share+0x281
   genunix`segspt_shmattach+0xd2
   genunix`as_map_locked+0x102
   genunix`as_map+0x4a
   shmsys`shmat+0x500
   shmsys`shmsys+0x59
   genunix`dtrace_systrace_syscall+0xc7
   unix`sys_syscall+0x17b
   606 

 

   unix`htable_lookup+0x8c
   unix`hat_unshare+0x7e
   genunix`segspt_shmunmap+0x81
   genunix`as_unmap+0x137
   shmsys`shm_detach+0x4b
   shmsys`shmdt+0x90
   shmsys`shmsys+0x6d
   genunix`dtrace_systrace_syscall+0xc7
   unix`sys_syscall+0x17b
   897

 

La fonction hat_share() semble assez intéressante à étudier. En regardant d'un peu plus près le code source, on constate l'élément suivant : suite à différentes conditions, soit la table de pages est partagée soit elle ne l'est pas (goto share - goto unshare). Si vous avez lu l'article précédant, un des avantages d'utiliser un segment ISM est justement de pouvois partager sa table de pages entre les différents processus se connectant à ce segment.

 

La fonction hati_load_command() exécutée dans la fonction hat_share() se déclenche uniquement dans le goto unshare. Tient donc, on utilise ISM et on ne partage pas la table de pages entre les différents processus !? Une des conditions provoque ce dysfonctionnement mais laquelle ? La taille de la SGA influence t'elle quelques choses ? Y a t'il une limite à la SGA ?

 

J'ai décidé de reprendre cette analyse sur différentes bases Oracles ayant des tailles de SGA différentes. Le résultat est surprenant... Pour chaque attachement à la SGA, la stack est identique. Cela veut dire que la table de pages n'est jamais partagée sur un Solaris 10x86 quand l'ISM est activé !!! Oupppsss !!! Cependant les temps de locks sont nettement inférieurs à la seconde et augementent quand la taille de la SGA augmente.

 

Pour résumé, l'ISM activé sur Solaris 10x86 ne partage pas la table de pages entre les différents processus qui y accèdent. Plus il y a d'attachements simultanés plus le phénomène s'accentue. Plus la taille de l'ISM est important plus les temps de locks sont importants. Avec toute ces petites informations j'ai ouvert un call chez Oracle. Le diagnostique s'avère exact, un bug a été ouvert en interne avec la référence suivante Bug 7127336: page table not shared for ISM segment on x64.

 

La correction du Bug semble assez complexe à mettre en oeuvre. J'ai donc travaillé avec les ingénieurs Oracle afin de trouver une solution temporaire à ce problème... Il va falloir attendre un peu pour les solutions...

 

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

 

 

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 1 commentaires

Samedi 28 janvier 2012 6 28 /01 /Jan /2012 16:32

 

Retour sur le dernier évènement Oracle The Extreme Performance Tour qui s'est déroulé le 25 janvier dernier à Paris (cet évènement se déroule dans plusieurs villes d'Europe). 

 

image001

 

Dans un magnifique cadre, devant 300 invités, Oracle a réaffirmé son ambition d'innover à travers sa gamme de produits hardware et systèmes. Avant de participer aux deux ateliers thématiques, les invités ont eu le plaisir d'écouter tour à tour Loic le Guisquet (Vice Président EMAA) et John Fowler (Vice Président Systems Oracle Corp).

 

Deux idées à retenir de ces discours :

  • Malgré la conjoncture délicate, c'est le moment d'innover !?
  • Oracle nous accompagne dans cette période délicate du mieux possible !? 

 

John Fowler est revenu sur l'offre complète Oracle Systems de la manière suivante :

  • Présentation d'une Roadmap Hardware : T4, Mxxxx, T5 (rien sur l'offre x86 !?)
  • Présentation de l'offre Extreme (Exadata, Exalogic, Exalytic, Big Data)
  • Présentation du Sparc Super Cluster (à base de T4-4)
  • Présentation de Solaris 11
  • Présentation de l'offre storage (SAN, NAS, Tape)

 

Pour ceux qui doutent encore de la périnité du Hardware Oracle et du système d'exploitation Solaris (sur les architectures Intel et Sparc), voici quelques messages clés à retenir : 

  • Fusion des deux puces Tx avec le Mxxxx
  • Investissement logiciels (Solaris et Unbreakable Linux) sur les architectures Intel et Sparc (pour Solaris)      
  • Renforcement de l'offre Extreme en essayant de l'adapter aux besoins des clients (boxes adaptées !?)

 

Etant moi-même intervenu pour le GUSES, je ne reviendrai pas sur l'ensemble des ateliers qui se sont déroulés. Au sujet de ma présentation, j'ai évoqué 3 retours d'expériences autour des technologies Solaris dans des environnements de production :

  • Consolidation d'une infrastructure de DEV/UAT sur Mxxxx avec des zones
  • Activation de la compression ZFS pour diminuer l'espace de stockage
  • Utilisation massive de zones dans un environnement de production avec le bon outilage

Ma présentation est disponible dans mon album.

 

En fin de journée, les invités ont pu assister à une table ronde sur l'innovation au service de la performance emmené par deux grands spécialistes : Joël de Rosnay et Pascal Picq. Discussion passionante autour de l'innovation, de ses enjeux, sa mise en oeuvre, ses origines, ses directions, etc.

 

Un évènement fort intéressant. N'oublier pas : ce type d'évènement (forcément commercial) permet surtout l'échange entre personnes d'entreprises issues de secteurs différents. Par exemple, j'ai été surpris de voir autant d'entreprises adopter l'architecture T4 avec Oracle VM (ldom) mais aussi leur intérêt grandissant pour Linux Unbreakable.

 

En conclusion, penser détenir la meilleur solution sans se remettre en cause (par l'innovation), peut provoquer votre "perte". Optez alors pour Solaris 11...

 

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

 

Par gloumps - Publié dans : divers
Ecrire un commentaire - Voir les 0 commentaires

Lundi 9 janvier 2012 1 09 /01 /Jan /2012 18:13

 

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 : 

 

Par gloumps - Publié dans : kernel
Ecrire un commentaire - Voir les 1 commentaires

Mardi 27 décembre 2011 2 27 /12 /Déc /2011 19:18

 

Le 25 janvier prochain Oracle France organise l'évènement suivant : Oracle Hardware Systems - The Extreme Performance Tour. Je me permet d'évoquer cette manifestation pour plusieurs raisons :

  • C'est toujours très enrichissant de rencontrer, échanger avec d'autres clients et / ou experts
  • Une présentation du Sparc Super Cluster (à base du T4-4)
  • Un témoignage du GUSES : Solaris plate-forme optimal pour les bases de données

 

Je vous invite donc rapidement à vous inscrire à cet évènement via l'agenda du GUSES ou directement sur Oracle.

Par gloumps - Publié dans : divers
Ecrire un commentaire - Voir les 0 commentaires

Présentation

Informations personnelles

  • Passionné d'informatique, je travaille actuellement comme expert système Solaris. Vous trouverez plus de renseignements à mon sujet sur mon profil Linkedin.

Flux RSS

  • Flux RSS des articles

Recherche

Calendrier

Août 2014
L M M J V S D
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
             
<< < > >>
Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Signaler un abus - Articles les plus commentés