Suivre ce blog
Administration Créer mon blog
26 octobre 2010 2 26 /10 /octobre /2010 19:27

 

C'est vraiment la tendance... Dtrace, Dtrace et toujours Dtrace... Gregg, Jim nous livrent des informations concernant la parution de leur prochain livre (Sur Dtrace bien sur...) Sans oublier une autre vidéo sur la performance avec la spécificité des interruptions où nos deux spécialistes sont rejoins par Roch Bourdonnais...

 

Bonne lecture  ici !!! 

Partager cet article

Published by gloumps - dans divers
commenter cet article
23 octobre 2010 6 23 /10 /octobre /2010 19:26

 

En attendant la parution du livre (le plus attendu pour moi) de Gregg Brendan et Jim Mauro sur Dtrace, je souhaite revenir sur la collection déjà disponible des livres autour de Oracle Solaris... Je les possède tous (qui a dit que je n'étais pas fan de Solaris) et même si je ne les ai pas tous lus entièrement je vais me permettre de faire quelques commentaires :


Solaris Internals 'Solaris 10 and OpenSolaris Kernel Architecture' (R. McDougall and J. Mauro)

Si comme moi vous aimez comprendre ce qui se passe dans le kernel, ce livre est indispensable. D'un niveau technique relativement élevé, les auteurs ont tenté de vulgariser les différentes notions du kernel Solaris et d'OpenSolaris. Attention, il ne s'agit pas d'un livre sur l'administration de Solaris, mais plutôt d'un livre orienté autour du développement, de l'analyse du kernel, du tuning.

A lire à tête reposée, sinon gare à l'insomnie.

 

Solaris Performance and Tools 'Dtrace and mdb techniques for Solaris 10 and OpenSolaris' (R. McDougall, J. Mauro and G. Brendan)

Le livre à posséder pour tous les administrateurs systèmes Solaris. Plusieurs références sont faites au livre Solaris Internal, mieux vaut posséder les deux. Comme l'annonce le titre, il s'agit d'un livre dédié à l'analyse du système Solaris, tous les outils systèmes sont décrits précisément avec des exemples à l'appui. Quelques notions sur l'analyse de core sont abordées dans le dernier chapitre mais on reste sur notre fin (dommage). Malgré tout, ce livre reste actuellement le meilleur dans cette catégorie, j'attends la même chose sous Linux mais je ne vois rien venir... (allez un petit troll).

 

Solaris Application Programming (D. Gove)

Comme son nom l'indique, ce livre est destiné aux programmeurs sous Solaris. Darryl Gove explique comment obtenir un code plus performant pour des applications s'exécutant sous Solaris avec différentes architectures matérielles. Si comme moi vous n'êtes pas un développeur d'application, ce livre est tout de même à posséder (avec les deux précédents). J'ai trouvé dans ce livre plusieurs cas pratiques me permettant de mieux cerner certains problèmes de performances (notamment sur les problèmes liés aux processeurs T et la gestion des opérations flottantes).

 

Solaris 10 System Administration Essentials (Solaris System Engineers)

Si vous débutez sous Oracle Solaris 10, ce livre est pour vous. Il couvre l'essentiel de l'administration d'Oracle Solaris : l'installation, le boot, les packages et patches, les systèmes de fichiers, les processus, le réseau, les zones, etc... Si vous avez déjà une bonne expérience sous Oracle Solaris je vous déconseille ce livre, il ne vous apportera rien de plus que vous ne savez déjà.

 

Solaris 10 Security Essentials (Solaris Security Engineers)

La sécurité... Beaucoup pensent qu'elle fait partie intégrante de notre métier et d'autres (comme moi) pensent que la complexité des systèmes d'aujourd'hui nécessitent des équipes dédiées à celle-ci. Je fais très peu de sécurité et même si ce sujet m'intéresse j'ai l'impression de ne plus trop savoir quoi faire. Tout cela pour dire que ce livre est très intéressant avec mon niveau actuel en sécurité. Il s'applique exclusivement à Solaris (très bon sujet chapitre sur RBAC). Cependant, si vous effectuez un travail de sécurité quotidienne sous Solaris, ce livre est peut-être un peu simpliste. A voir...

 

Solaris 10 ZFS Essentials (S. Watanabe)

On ne présente plus ZFS : ce système de fichiers révolutionnaire. Et pourtant, j'en connais encore qui ne l'utilise pas sous Solaris... Si vous l'utilisez au quotidien, évitez d'acheter ce livre, il ne vous servira absolument pas. Par contre si vous débutez sous ZFS, achetez le sans hésiter. Il évitera de vous faire faire quelques erreurs.

 

Oracle Solaris 10 System Virtualization Essentials (J. Victor, J. Savit, G. Combs, S. Hayler and B. Netherton)

Ce livre couvre toutes les solutions de virtualisation sous Oracle Solaris et ceux sous les différentes architectures matérielles : partitionnement physique (Mx000), Oracle VM server pour Sparc (Ldoms), Oracle VM Virtual Box, Oracle Solaris Containers et même Oracle Solaris 10 sur des hyperviseurs x86. Le premier chapitre explique les atouts de la virtualisation qui doit être acquis depuis longtemps (je vous le souhaite) et décrit succinctement les solutions disponibles sous Oracle Solaris 10. Chaque solution est par la suite expliquée. Du déjà vu... oui mais ce livre reste un très bon ouvrage à laisser trainer près de son DSI si aucune décision de virtualisation n'a été mise en oeuvre pour vos serveurs tournants sous Oracle Solaris.

 

Oracle Solaris Cluster Essentials (T. Read)

Vous ne trouverez pas dans ce livre comment corriger un problème sur votre Cluster Oracle Solaris. Désolé... Vous trouverez dans ce livre la description des clusters disponibles sous Oracle Solaris (Oracle Solaris Cluster, Géo Cluster, Oracle RAC et Oracle Solaris Cluster...), leur cas d'utilisation et leur mise en oeuvre. Très bon ouvrage à posséder même si il n'est pas technique.

 

OpenSparc Internals (D. Weaver)

Très bon ouvrage sur l'architecture des processeurs T. Orienté programmeurs, ce livre couvre les deux premières puces T1 et T2. On comprend mieux l'intérêt de ces puces et surtout leur cas d'utilisation. Un peu difficile à lire (en tout cas pour moi)

 

Eh bien, vous savez maintenant quoi faire de vos soirée d'hiver. Si vous ne saviez pas quoi demander à Noël, vous le savez.. Comme vous pouvez le lire, il existe de nombreux ouvrages de qualité sur Oracle Solaris... Bonne lecture...

 

Partager cet article

Published by gloumps - dans divers
commenter cet article
22 octobre 2010 5 22 /10 /octobre /2010 20:50

 

L'association GUSES a le plaisir de vous inviter à sa prochaine manifestation qui se déroulera le 4 novembre prochain. Le sujet est le suivant :

 

Venez découvrir toutes les nouveautés autour des technologies Oracle Solaris (Oracle Solaris 11, Exalogic, Sparc T3) qui ont été présentées lors de l'évènement annuel d'Oracle qui s'est tenu au mois de septembre dernier. Eric Bezille, chief technologist Oracle Hardware Business Unit France, reviendra sur tous les points importants qui ont été évoqués lors de cette manifestation. Profitez de cette occasion pour venir évoquer l'avenir d'Oracle Solaris...

 

Cette conférence a lieu à l'adresse suivante :

 

Oracle Customer Briefing Centre,
Paris Oracle - Sun Microsystems France SAS - 10ème étage, Capital 8, 32 Monceau, 75008 Paris

(A partir de 19h30)

 

Event linkedin
Event guses 
Blog d'Eric Bezille

Partager cet article

Published by gloumps - dans divers
commenter cet article
16 octobre 2010 6 16 /10 /octobre /2010 17:54

 

C'est un problème que j'ai rencontré sous Solaris 10x86 sur du matériel Oracle Galaxy (x4100, x4150, ...). Les serveurs hébergent différentes applications type RMDS (Application pour les transactions boursières). Mais voilà que de temps en temps, le démon système fmd occupait tout les ressources CPU. Cela provoquait bien évidemment des latences applicatives. La solution semblait évidante : un bug avec le démon fmd. Et pourtant...

 

fmd est le démon pour le gestionnaire d'erreur de Solaris 10 nommé Solaris Fault Manager. Pour simplifier (désolé pour les puristes), il permet la détection de pannes hardware ou software. Il introduit aussi des composants d'autorétablissements. Désactiver le démon résolvait le problème mais la suppression de cette fonctionnalité n'était pas la meilleur solution (à mon sens).

 

Bizarrement le support SUN n'a pas été d'un très grand secours. Et la seule solution proposée était de désactiver le démon... La persévérance associée à un excellant outil comme Dtrace m'a permis de comprendre l'origine du problème et de le résoudre définitivement.

 

On commence par le début...

 

# vmstat 3
  kthr      memory            page            disk          faults      cpu
 r b w   swap   free  re  mf pi po fr de sr f0 s0 s1 s2   in   sy   cs us sy id
 0 0 0 8797840 4599880 10  20  0  0  0  0 26 -0  1  2  5  306  185  226  0  2 98
 0 0 0 8787000 4557880  6  17  0  0  0  0  0  0  0  0  0  309  114  152  0  1 99
 0 0 0 8786200 4557360  2   2  0  0  0  0  0  0  0  0  0  308  104  152  0  1 99
 0 0 0 8786200 4557360  2   2  0  0  0  0  0  0  0  0  0  305  102  148  0  1 99
 0 0 0 8786200 4557360  2   2  0  0  0  0  0  0  0  0  0  308  104  150  0  1 99
 0 0 0 8786200 4557360  2   2  0  0  0  0  0  0  0  0  0  305  102  146  0  1 99
[...]

 

Bizarrement la charge CPU m'indiquait absolument rien. L'application réceptionne des flux réseaux, effectue une opération atomique avec les données reçues et renvoie le tout. Les opérations sont rapides (de l'ordre de la ms). L'outil vmstat m'était pas d'une très grande utilité.

 

# prstat
[...]
PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
934 root      13M  9400K cpu3    59    0   3:34:00 3.0% fmd/8
637 root     3712K 2960K cpu0    59    0   0:00:00 0.0% prstat/1
120 root     5432K 2828K sleep   59    0   0:00:00 0.0% nscd/29
604 root     6368K 3608K sleep   59    0   0:00:00 0.0% sshd/1
305 daemon   2816K 1200K sleep   59    0   0:00:00 0.0% rpcbind/1
310 daemon   2780K 1616K sleep   59    0   0:00:00 0.0% statd/1
[...] 

 

Première indication intéressante, le process fmd consommait effectivement beaucoup de temps CPU (temps cumulé) et utilisait environ 3% de CPU. Cela peut paraître très peu mais pour ce type d'application c'est déjà beaucoup trop. Mais que consommait exactement le process fmd ?

 

# prstat -mL -p 934
   PID USERNAME USR SYS  TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
   934 root     0.0 0.0  0.0 0.0 0.0 100 0.0 0.0   0   0   0   0 fmd/8
   934 root     0.0 0.0  0.0 0.0 0.0 0.0 100 0.0   0   0   0   0 fmd/7
   934 root     0.0 23.0 0.0 0.0 0.0 100 0.0 0.0   0   0   0   0 fmd/6
   934 root     0.0 0.0  0.0 0.0 0.0 0.0 100 0.0   0   0   0   0 fmd/5
   934 root     0.0 0.0  0.0 0.0 0.0 100 0.0 0.0   0   0   0   0 fmd/4
   934 root     0.0 0.0  0.0 0.0 0.0 100 0.0 0.0   0   0   0   0 fmd/3
   934 root     0.0 0.0  0.0 0.0 0.0 0.0 100 0.0   0   0   0   0 fmd/2
   934 root     0.0 0.0  0.0 0.0 0.0 0.0 100 0.0   0   0   0   0 fmd/1

 

Un lwpid avait une utilisation très anormal de temps système. L'outil Solaris Fault Manager est orienté modules. Il est facile de connaître les différents modules utilisés mais surtout leurs statistiques.

 

# fmstat
module             ev_recv ev_acpt wait  svc_t  %w  %b  open solve  memsz  bufsz
cpumem-retire            0       0  0.0    0.0   0   0     0     0      0      0
disk-transport           0       0  0.0  286.3   0   0     0     0    32b      0
eft                      0       0  0.0    0.0   0   0     0     0   1.2M      0
ext-event-transport      0       0  0.0    0.0   0   0     0     0      0      0
fabric-xlate             0       0  0.0    0.0   0   0     0     0      0      0
fmd-self-diagnosis       2       0  0.0  320.9   0   0     0     0      0      0
io-retire                0       0  0.0    0.0   0   0     0     0      0      0
snmp-trapgen             0       0  0.0  963.1   0   0     0     0      0      0
sp-monitor               0       0  100  120.1   80  0     0     0      0      0
[...]

 

Le module sp-monitor semblait avoir un comportement vraiment bizarre. Le module sp-monitor se connecte au service processor via le pseudo device /dev/bmc et récupère différentes informations de télémétrie (et autres choses...).

 

Une piste sérieuse se dégageait. J'ai utilisé le script hotkernel pour voir rapidement la consommation de ma CPU par rapport aux fonctions et modules (voir la boite à outils de Gregg Brendan).

 

FUNCTION                     COUNT      PCNT                             
[...]
genunix`sigdiffset           100        0.0%
bmc`kcs_read                 120        0.0%
genunix`sigorset             127        0.0%
genunix`issig_justlooking    687        0.2%
bmc`kcs_status              3894        0.9%
unix`i86_mwait            407904        98.6%                                     

 

MODULE                     COUNT       PCNT                 
[...]
ip                           11        0.0%
ipsecah                      18        0.0%
genunix                     240        0.1%
bmc                        4957        1.2%
unix                     421921        98.8%

 

La CPU consommée l'était par les fonctions kcs_read et kcs_status du module bmc. J'ai utilisé par la suite le script errinfo (légèrement modifié) pour obtenir le code d'erreur du module bmc. En fait la connexion au service processor via le pseudo device bmc ne fonctionnait plus. L'installation du package ipmitool a par ailleurs confirmé ce problème.

 

Le fait d'unloader le module sp-monitor de la configuration fmd résolvait le problème de consommation CPU. Le problème de communication entre Oracle Solaris 10 et le service processor a été corrigé en appliquant le dernier firmware pour les serveurs Galaxy. Rien de très compliqué en fait... L'utilisation d'un outil comme Dtrace m'a permis rapidement de remonter à l'origine du problème. Il y a certainement d'autres méthodes d'investigations plus efficace que celle-ci mais le résultat restera le même : il n'y a plus de problème. Par contre je suis preneur de toutes informations.

 

Partager cet article

Published by gloumps - dans kernel
commenter cet article
13 octobre 2010 3 13 /10 /octobre /2010 22:54

 

Return to a problem with VxVM after adding san disks. By analyzing the core and the logs of daemon, I found (and understood) the origin of the problem.

 

It's a classical error but the root cause a little less traditional. The vxconfigd daemon not running just after adding disks. Why ? 

 

# vxdisk list
VxVM vxdisk ERROR V-5-1-684 IPC failure: Configuration daemon is not accessible

 

Nothing serious Doctor ? I decide to restart the daemon 

 

# vxconfigd -k
VxVM vxconfigd ERROR V-5-1-0 Segmentation violation - core dumped

 

It's bad start, hummm look at this core

 

# ls -l /core
-rw------- 1 root root 13221414 Sep 20 18:50 /core

# file /core
/core: ELF 32-bit MSB core file SPARC Version 1, from 'vxconfigd'

# mdb /core
Loading modules: [ libc.so.1 libnvpair.so.1 libavl.so.1 libuutil.so.1 ld.so.1 ]
> $C
ffbfea58 ddl_migration_devlist_removed+0x198(4820c0, 131b8, 2cf928, 2bc770, 50000, 482dd8)
ffbfeab8 ddl_check_migration_of_devices+0x9c(4b7598, 4ccdf8, ffbfeb7c, 4820c0, 5c00,0)
ffbfeb18 ddl_reconfigure_all+0x26c(2c254c, 4820c0, 2bc770, 50000, 3400, 2cf8dc)
ffbfeb80 ddl_find_devices_in_system+0x3f0(11400, 0, 5de8, 2bc770, 0, 2c0ad0)
ffbff110 find_devices_in_system+0x28(2, 0, 276664, 2cb214, 11, 276800)
ffbff170 mode_set+0x184(2, ffbff954, 2cb214, 2cb250, 0,2c0000)
ffbff8f0 setup_mode+0x24(2, 274400, 0, 2c0800, a39, 274400)
ffbff958 startup+0x284(8fa656a0, 2dcc00, 2c0800, 2c0800, 274400, 657a)
ffbff9c8 main+0xcac(2, ffbffb1c, ffffffff, 0, ffbffbf0, 0)
ffbffab8_start+0x108(0, 0, 0, 0, 0, 0)

> ddl_migration_devlist_removed+0x198::dis
ddl_migration_devlist_removed+0x170: ld [%l1], %o4
ddl_migration_devlist_removed+0x174: ba+0xb8 <ddl_migration_devlist_removed+0x22c>
ddl_migration_devlist_removed+0x178: ld [%l1 + 0xc], %l1
ddl_migration_devlist_removed+0x17c: ld [%l1 + 0x4], %o5
ddl_migration_devlist_removed+0x180: ld [%l1 + 0x8], %l2
ddl_migration_devlist_removed+0x184: btst 0x2, %o5
ddl_migration_devlist_removed+0x188: bne,pn %icc, +0x48 <ddl_migration_devlist_removed+0x1d0>
ddl_migration_devlist_removed+0x18c: btst 0x8,%o5
ddl_migration_devlist_removed+0x190: bne,pn %icc, +0x40 <ddl_migration_devlist_removed+0x1d0>
ddl_migration_devlist_removed+0x194: add %i4, 0x9, %o0
ddl_migration_devlist_removed+0x198: ld [%l2 + 0x8], %g5
ddl_migration_devlist_removed+0x19c: sethi %hi(0x2d400), %g1
ddl_migration_devlist_removed+0x1a0: sethi %hi(0x5400), %o1
ddl_migration_devlist_removed+0x1a4: ld [%l2 + 0xc], %g3
ddl_migration_devlist_removed+0x1a8: xor %g1, -0x2e4, %o7
ddl_migration_devlist_removed+0x1ac: add %o1, 0x148, %o1
ddl_migration_devlist_removed+0x1b0: add %i3, %o7, %o2
ddl_migration_devlist_removed+0x1b4: sub %g5, 0x1, %g4
ddl_migration_devlist_removed+0x1b8: mov %i2, %o3
ddl_migration_devlist_removed+0x1bc: st %g4, [%l2 + 0x8]
ddl_migration_devlist_removed+0x1c0: add %g3, 0x1, %g2

> ::regs
%g0 = 0x00000000 %l0 = 0xfffffffe
%g1 = 0x0015e160 ddl_check_if_exists_in_prop_list+0x58 %l1 = 0x00485340
%g2 = 0x00000000 %l2 = 0x00000000
%g3 = 0x002dcc00 vxconfigd`progname %l3 = 0x00000000
%g4 = 0x002c0800 vxconfigd`ioctls+0x318 %l4 = 0x00000001
%g5 = 0x00000088 %l5 = 0x004820e8
%g6 = 0x00000000 %l6 = 0x00482112
%g7 = 0xff0d2a00 %l7 = 0x004b7598
%o0 = 0x00050009 vold_change_common+0x1751 %i0 = 0x004820c0
%o1 = 0x40000025 %i1 = 0x000131b8
%o2 = 0x002bc770 %i2 = 0x002cf928
%o3 = 0x00000000 %i3 = 0x002bc770
%o4 = 0x00485340 %i4 = 0x00050000 vold_change_common+0x1748
%o5 = 0x40000025 %i5 = 0x00482dd8
%o6 = 0xffbfea58 %i6 = 0xffbfeab8
%o7 = 0x00157c7c ddl_migration_devlist_removed+0x11c %i7 = 0x00157a7c ddl_check_migration_of_devices+0x9c

%psr = 0xfe401002 impl=0xf ver=0xe icc=nZvc
                  ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x2

%y   = 0x00000000
%pc  = 0x00157cf8 ddl_migration_devlist_removed+0x198
%npc = 0x00157cfc ddl_migration_devlist_removed+0x19c
%sp  = 0xffbfea58
%fp  = 0xffbfeab8

%wim = 0x00000000
%tbr = 0x00000000

 

It's in a function 'ddl_migration_devlist_removed' that the problem is... Without a source code, it's more difficult to understand. So I change the method...

 

# vxconfigd -x 9 -k -x log -x logfile=/tmp/vxconfigd.out
...
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
.. vxconfigd DEBUG V-5-1-14387 ddl_check_migration_of_device: oldnode is NULL
...

 

Strange, no ? The same function as in the core. But what is DDL ? DDL (Device Discovery Layer) is the process of locating and identifying disks attached to a host. What are the disks connected to my server

 

# egrep Enclosure /tmp/vxconfigd.out
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:CLR-A/PF:EMC_CLARiiON:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:A/A:EMC_CLARiiON:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300471:0:EMC:A/A:EMC:834
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300446:0:EMC:A/A:EMC:834
.. vxconfigd DEBUG V-5-1-14475 Enclosure is DISKS:0:SEAGATE:Disk:Disk:514
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300446:50:EMC:A/A:PP_EMC:194
.. vxconfigd DEBUG V-5-1-14475 Enclosure is DISKS:5:SEAGATE:Disk:Disk:2
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:52:DGC:A/A:PP_EMC_CLARiiON:194
.. vxconfigd DEBUG V-5-1-14475 Enclosure is 000290300471:50:EMC:A/A:PP_EMC:194

 

Looking at the vxconfigd.log, we noticed the following

 

.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:CLR A/PF:EMC_CLARIION:832
.. vxconfigd DEBUG V-5-1-14475 Enclosure is CK200072700055:0:DGC:A/A:EMC_CLARIION:832

 

The same enclosure is being seen as both ALUA and AP/F. Google is my friend, after a little research on the web I found the following bug by Symantec: TECH76277. This root is simple: this can occur if the array had existing LUNS configured as AP/F. Subsequently, some ALUA LUNS were added. This mixed configuration can cause problems with DMP. An the solution is: after changing all LUNS to either AP/F or ALUA, the problem is resolved.

 

Partager cet article

Published by gloumps - dans lvm
commenter cet article
11 octobre 2010 1 11 /10 /octobre /2010 22:45

 

Le rêve américain... J'ai eu la chance de passer 3 semaines en Californie (en septembre dernier). Geek comme je suis j'en ai profité pour faire un petit passage entre Berkley et la Silicon Valley. Quelques photos de mon voyage sont disponibles ici...

Partager cet article

Published by gloumps - dans divers
commenter cet article
11 octobre 2010 1 11 /10 /octobre /2010 21:47

 

J'ai déjà écris un article sur ce sujet (ici) mais je permet d'en rajouter encore un peu suite à la parution (en début de mois) d'une interview de Gregg Brendan sur OTN. Gregg nous explique pourquoi Dtrace est devenu un outil indispensable pour tout Administrateur système qui se respecte. Je me répète mais l'utilisation de Dtrace nous permet enfin de mieux cerner notre système. A signaler prochainement la parution d'un livre Dtrace écrit par Gregg et Jim (Mauro). Vivement décembre.

 

En attendant, vous pouvez toujours vous procurer l'excellant Solaris Performance and Tools: Dtrace and MDB.

Partager cet article

Published by gloumps - dans divers
commenter cet article
7 octobre 2010 4 07 /10 /octobre /2010 17:34

 

Il a fallu attendre le mois d'août pour obtenir enfin une communication officielle de la part d'Oracle au sujet de Solaris. Oufff de soulagement, après plusieurs mois de flou, Larry Allison, par l'intermédiaire de John Fowler officialisait enfin la future version de Solaris (Oracle Solaris 11) et du même coup proposait une nouvelle version de Solaris 10 (Oracle Solaris 10u9).

 

L'Oracle Open World qui s'est déroulé mi-septembre a permis aussi de rassurer (enfin) les clients que nous sommes avec des annonces fortes de la part d'Oracle : sortie de la gamme T3, roadmap de la gamme Mx sur 5 ans, investissements importants dans l'os Oracle Solaris et disponibilité d'une version du future Exalogic sous Solaris 11. Je me permet de vous rediriger vers le blog d'Eric Bezille sur ce sujet qui détaille un peu plus ces nouveautés.

 

Pour ceux qui n'ont pas eu la chance de se déplacer à San Francisco pour assister à cette évènement, Oracle vient d'organiser (aujourd'hui même - j'en sors juste) l'event suivant : "Next-Generation Datacenter: optimize with Oracle". Cet event structuré autour de différents tracks nous a permis de mieux cerner les visions d'Oracle sous ces différentes offres.

 

Ce que j'en retiens : OpenSolaris n'est pas mort mais devient Oracle Solaris 11 Express avec peut être moins de visibilité du code source, la gamme SPARC n'est pas morte loin de là (arrivé du T3, investissement dans les Mx), l'Exadata et l'Exalogic : deux éléments importants dans nos futures datacenters, Oracle Solaris 11 promet d'être un OS aussi novateur qu'à pu l'être Solaris 10... 

 

Des sujets restent cependant vagues : Oracle VM Server qui utilise Xen alors que Redhat propose désormais Kvm (OVM est basé sur une Redhat), choix d'un gestionnaires de fichiers unifiés (ZFS, ASM, ACF, OCFS, ...), stratégie de consolidation x86 (Oracle Linux ou Oracle Solaris), l'Exalogic une boîte noir... Mais bon on ne peut pas tout avoir d'un coup...

 

J'entendais beaucoup de monde annoncer la mort de Solaris et Sparc me voilà vraiment rassuré et confiant dans l'avenir... enfin j'espère.

Partager cet article

Published by gloumps - dans divers
commenter cet article
17 août 2010 2 17 /08 /août /2010 21:56

 

L'une des tâches les plus intéressantes de notre travail (ceci est mon avis) est de comprendre ce qui se passe dans le système. Cette tâche n'est pas simple : la gestion des processus, le dispatcher, l'interaction avec le matériel, la gestion des I/O, ... nécessitent des connaissances variées et ceux dans différents domaines.

 

Mais voilà, Solaris 10 nous a permis de mieux comprendre tout ce qui se passe sur notre système. Dtrace est un outil révolutionnaire encore sous exploité dans notre métier (j'entends ingénieur système). Peu de personne l'utilise mais surtout peu de personne comprenne son intérêt. Cela fait maintenant 5 ans que Solaris 10 existe et je suis encore très surpris de croiser des "admin sys" qui ne l'utilise pas ou très peu... 

 

Utiliser Dtrace doit devenir aussi naturel que te lancer un "iostat" ou un "prstat" lors de l'analyse d'un système. Dtrace permet  surtout de comprendre ce que fait réellement une application ou plus simplement quelle fonction le kernel utilise pour traiter une opération. 

 

Quand je dois analyser un système Linux, je me retrouve complètement perdu. Aucune commande pour comprendre réellement ce qui se passe et pourquoi cela se passe. Je me vois mal parcourir toutes les lignes de code du noyau ? Depuis peu et notons le, Linux intègre enfin un outil d'analyse : systemtap... Ouffff mais bon... Je suis déçu, le code noyau change tellement vite que le script écrit sur une version x du noyau ne fonctionne plus sur la version y... Vous avez le droit de "troller" après ça. 

 

Ci-joint quelques liens pour votre culture : 

Dtrace : link
systemtap : link

 

Pour rappel :

En Mai/Juin dernier, William Roche et Jean-Christophe Martin nous ont présenter deux sessions relatives à Dtrace lors des mensuelles du GUSES. Le résumé des présentations est disponible sur le site d'Eric Bezille ici.

 

Pour résumer, il est tend de passer à Dtrace (et vivement un outil digne de ce nom sur Linux mais bon ça j'y crois moins).

 

Partager cet article

Published by gloumps - dans divers
commenter cet article
16 août 2010 1 16 /08 /août /2010 21:04

 

 

I'm really surprised when I still see Solaris servers configured without the possibility of taking a dump. These next few lines explain how to do that especially for Solaris x86 (use interrupt NMI).

 

 

To achieve this, it's necessary to configure several elements in the Solaris system:

  • Activation system in debug mode
  • Correct setting for taking dump
  • System configuration for NMI interrupts

 

How to start in debug mode Solaris 10x86 ? It's really simple, just add parameter "kadb" at the end of line "multiboot" in the file "menu.lst" then reboot.

 

As you can see below:

 

# pwd
/rpool/boot/grub

# cat menu.lst
[...]
title s10x_u9wos_14a
bootfs rpool/ROOT/s10x_u9wos_14a
findroot (pool_rpool,0,a)
kernel$ /platform/i86pc/multiboot -B console=ttyb,$ZFS-BOOTFS kadb
module /platform/i86pc/boot_archive

[...] 

 

How to configure correct setting for taking dump ? Just use the command "dumpadm". Two things to check: the dump device and the savecore directory exist with the correct size (the size depends on RAM - two different policies on this subjetc: the size of dump device is the same as the RAM or not).

 

For exemple:

 

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash/zlap
  Savecore enabled: no
   Save compressed: on

# prtconf | grep -i memory
Memory size: 16384 Megabytes

# zfs get volsize rpool/dump
NAME           PROPERTY  VALUE    SOURCE
rpool/dump  volsize       512M     -

# df -h /var/crash/zlap
Filesystem            Size  Used Avail Use% Mounted on
rpool/ROOT/solaris     54G  9.9G   16G  39% / 

 

How to configure system for NMI interrupt ? Just add the following lines in the file /etc/system then reboot.

 

For exemple: 

 

# egrep apic /etc/system
set pcplusmp:apic_kmdb_on_nmi=1
set pcplusmp:apic_panic_on_nmi=1

 

Now, if the system hang, you can send an interrupt NMI and thus take a dump. Either you use the "ipmi" command (if ipmi command are available on ILOM's server) or you use the website of the ILOM's server to generate an interrupt NMI.

 

For exemple (ipmi command):

 

# ipmitool -I lanplus -H server-rsc -U root chassis power diag

 

 

A simple demonstration...

 

On server :

 

$ ssh zlap

 

# uname -a

SunOS zlap 5.10 Generic_142910-17 i86pc i386 i86pc

# prtdiag

System Configuration: HP ProLiant DL360 G5

BIOS Configuration: HP P58 05/18/2009

BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)

[...]

 

 

On Rilo server  :

 

$ ssh admin@zlap-rsc

root@zlap-rsc's password:
User:root logged-in to ILOLD75MU6996.(XXX.XXX.XXX.XX)
iLO 2 Advanced 2.05 at 15:38:15 Dec 17 2009
Server Name: DL360G5P-34-13
Server Power: On

</>hpiLO->
</>hpiLO-> nmi server

</>hpiLO-> vsp

 

Starting virtual serial port.
Press 'ESC (' to return to the CLI Session.

</>hpiLO-> Virtual Serial Port active: IO=0x02F8 INT=3

[1]> 
[1]> ::showrev
Hostname: zlap
Release: 5.10
Kernel architecture: i86pc
Application architecture: amd64
Kernel version: SunOS 5.10 i86pc Generic_142910-17
Platform: i86pc

[1]> $<systemdump
nopanicdebug:   0               =       0x1

panic[cpu1]/thread=fffffe80005e0c60: BAD TRAP: type=e (#pf Page fault) rp=fffffe80005e0980 addr=0 occurred in module "<unknown>" due to a NULL pointer dereference

sched: #pf Page fault
Bad kernel fault at addr=0x0
pid=0, pc=0x0, sp=0xfffffe80005e0a78, eflags=0x10002
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f0<xmme,fxsr,pge,mce,pae,pse>
cr2: 0 cr3: 14717000 cr8: c
        rdi: fffffffffbc7eab0 rsi:              2f8 rdx:              2f8
        rcx:                a  r8:                0  r9: ffffffffa4f71c90
        rax: fffffffffbcecbe0 rbx: ffffffffef8f1250 rbp: fffffe80005e0a80
        r10: fffffe80005e09c0 r11:                0 r12: fffffe80005e0af0
        r13:                1 r14: fffffffffbc561c0 r15:                1
        fsb:                0 gsb: ffffffffa44fb800  ds:               43
         es:               43  fs:                0  gs:              1c3
        trp:                e err:                0 rip:                0
         cs:               28 rfl:            10002 rsp: fffffe80005e0a78
         ss:               30

fffffe80005e0890 unix:die+da ()
fffffe80005e0970 unix:trap+5e6 ()
fffffe80005e0980 unix:cmntrap+140 ()
fffffe80005e0a80 0 ()
fffffe80005e0a90 genunix:kdi_dvec_enter+d ()
fffffe80005e0ab0 unix:debug_enter+66 ()
fffffe80005e0ac0 pcplusmp:apic_nmi_intr+94 ()
fffffe80005e0ae0 unix:av_dispatch_nmivect+1f ()
fffffe80005e0af0 unix:nmiint+17e ()
fffffe80005e0be0 unix:i86_mwait+d ()
fffffe80005e0c20 unix:cpu_idle_mwait+125 ()
fffffe80005e0c40 unix:idle+89 ()
fffffe80005e0c50 unix:thread_start+8 ()

syncing file systems... done
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
 0:01 100% done
100% done: 320938 pages dumped, dump succeeded
rebooting...

 

 

It's very simply... no ?

 

 

For you computer culture, here are some links on the topic:

 

 

 

 

 

Partager cet article

Published by gloumps - dans kernel
commenter cet article