Lundi 22 août 2011 1 22 /08 /Août /2011 21:00

 

Pour bien commencer la rentrée scolaire, Oracle University organise une formation de 3 jours les 5, 6 et 7 septembre dans les locaux de Colombes sur Solaris 11 (pas Solaris 11 Express). Si cela vous intéresse, vous pouvez contacter Oriana Nguyen-Van.

 

Ce cours à pour objectif de couvrir :

  • Install Oracle Solaris 11
  • Manage software updates in Oracle Solaris 11
  • Explain the new ZFS file system features and enhancements
  • Administer Containers in Oracle Solaris 11
  • Manage virtual networks in Oracle Solaris 11
  • Describe the new features and enhancements in Oracle Solaris 11
  • Describe new user management features and enhancements
  • Explain the new security administration features and enhancements


Vous trouverez les détails du contenu de cette formation à l'adresse suivante : TRANSITION TO ORACLE SOLARIS 11 (EARLY ADOPTER).

 

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

Samedi 20 août 2011 6 20 /08 /Août /2011 10:05

 

Petit sujet qui m'a tenu en haleine un petit moment... Pour situer un peu le contexte, nous obtenions des hangs sur plusieurs bases de données Oracle (hang pouvant dépasser l'heure) situés sur plusieurs serveurs et plusieurs baies SAN. La seule alerte obtenue était ce message d'erreur "WARNING: aiowait timed out" dans l'alert.log des bases. Pour le support Oracle bases de données, ce type de message provient d'un problème sur la couche IO du serveur.

 

Analysons déjà ce que veut dire cette alerte : Oracle effectue une écriture de type KAIO sur un fichier. Le temps de réalisation de cette écriture ne doit pas dépasser 10 minutes sinon Oracle l'indique via ce message d'erreur. Ce qui veut dire qu'entre la demande et la réalisation de cette écriture il y a eu un délai supérieur à 10 minutes... 10 minutes pour réaliser une IO ??? De quoi devenir fou...

 

Ne disposant d'aucune alerte système, l'investigation commençait difficilement. La première chose à faire dans ce type de cas s'est d'obtenir un maximum de traces pour pouvoir investiguer correctement le problème. Nous avons donc mis en place un script détectant l'anomalie dans l'alert.log des bases. Ce script exécute à la fois un Livecore et une prise de traces via l'outil Guds (je me suis inspiré de l'article suivant).

 

Je vous passe le fait que le script n'a pas fonctionné tout le temps... Les prises de traces exploitables n'ont absolument rien montré qui pouvaient expliquer notre problème (rien dans les traces iostat, la charge des systèmes était correcte, etc..). Je me suis concentré uniquement sur les IO. Pour ne pas m'éparpiller entre les différents serveurs, baies, bases, j'ai décidé d'analyser le problème sur une seule base (un serveur et une baie mutualisés).

 

J'ai écrit un petit script Dtrace me permettant de calculer le temps passé pour chaque appel KAIO. Ceci m'a permis de vérifier, cette latence de 10 minutes que la base de données Oracle indiquée.

 

# cat ./aiowait.d
#!/usr/sbin/dtrace -qs

 fbt:kaio:aiowait:entry
/execname == "oracle"/
{
        self->ts = timestamp;
}

fbt:kaio:aiowait:return
/self->ts && (timestamp - self->ts)/1000000 > 60/
{
        self->duration = (timestamp - self->ts)/1000000;
        printf("%Y %20s %8d %12d %12d\n", walltimestamp, execname, pid, tid, self->duration);
        self->duration = 0;
}

 

# ./aiowait.d
[...]
2011 Jul 19 23:45:40       oracle    14583       1        67
2011 Jul 19 23:45:39       oracle    14583       1        89
2011 Jul 19 23:45:40       oracle    14583       1        61
2011 Jul 19 23:45:40       oracle      714       1       127
[...]
2011 Jul 19 23:58:39       oracle    14583       1    600100
2011 Jul 19 23:58:39       oracle    14583       1      3014
2011 Jul 19 23:58:38       oracle    14583       1       908
2011 Jul 19 23:58:39       oracle    14583       1     36730 
[...] 

 

Si vous interprétez correctement cet output, on remarque des temps de latence entre l'entrée et la sortie de la fonction aiowait supérieurs à 60 millisecondes pour la plupart des KAIO mais surtout une latence supérieur à 10 minutes. Incroyable voilà ce que je me suis dis... Une latence de 10 minutes pour une écriture... Oracle dit vrai !!!

 

Ce qu'il faut bien comprendre c'est qu'une demande de lecture et / ou écriture se décompose en plusieurs couches dans le système. Une couche logique (opération vfs, opération vnode, file system, cache) et ensuite une couche physique. Suite à ma première constatation j'ai d'abord vérifié la couche physique (c'est la plus facile à analyser). Pour ce faire, j'ai utilisé le petit script Dtrace suivant.

 

# cat ./fsiolantency.d
#!/usr/sbin/dtrace -Cs

#pragma D option quiet
#pragma D option defaultargs

dtrace:::BEGIN
{
#if defined(ZONENAME)
        uzone = ZONENAME;
#else
        uzone = "";
#endif

#if defined(EXECNAME)
        uexec = EXECNAME;
#else
        uexec = "";
#endif

#define PROBE_SWITCH \
        ((uzone == "" || uzone == zonename) && \
                (uexec == "" || uexec == execname))
}

io:::start
/PROBE_SWITCH/
{
        start[arg0] = timestamp;
}

io:::done
/start[arg0]/
{
        @time["disk I/O latency (ns)", args[2]->fi_mount, args[0]->b_flags & B_READ ? "R" : "W"] = quantize(timestamp - start[arg0]);
        start[arg0] = 0;
}


# ./fsiolantency.d -D ZONENAME='"zone1'" -D EXECNAME='"oracle"'
^C 

disk I/O latency (ns)     /zones/zone01/root/ZONE01/oradata02         W                                              
           value  ------------- Distribution ------------- count
         1048576 |                                         0
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@           1112
         4194304 |@@@@@@@@@@                               104
         8388608 |                                         0

 disk I/O latency (ns)    /zones/zone01/root/ZONE01/oradata03         R                                             
           value  ------------- Distribution ------------- count
          131072 |                                         0
          262144 |@@@@@@@@@@@@@@@@@@@                      2408
          524288 |@@                                       231
         1048576 |@@                                       230
         2097152 |                                         0
         4194304 |@@@@@                                    1023
         8388608 |@@@@@@@@@@@@                             1940
        16777216 |                                         0

 disk I/O latency (ns)    /zones/zone01/root/ZONE01/oraredo01         W                                             
           value  ------------- Distribution ------------- count
         1048576 |                                         0
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@                  2013
         4194304 |@@@@@@@@@@@@@@@@@                        1870
         8388608 |                                         0

 disk I/O latency (ns)    /zones/zone01/root/ZONE01/oradata01         R                                              
           value  ------------- Distribution ------------- count
          131072 |                                         0
          262144 |@@@@@@@                                  498
          524288 |@@                                       156
         1048576 |                                         0
         2097152 |                                         0
         4194304 |@@@@@@@@@@@@                             750
         8388608 |@@@@@@@@@@@@@@@@@@                       1134
        16777216 |@@                                       134
        33554432 |                                         0

 disk I/O latency (ns)    <none>                                      R                                              
           value  ------------- Distribution ------------- count
          131072 |                                         0
          262144 |@@@@@@@@@@@@@@@                          158
          524288 |@@                                       27
         1048576 |                                         0
         2097152 |                                         0
         4194304 |@@@@@@@@@@@@@                            139
         8388608 |@@@@@@@@@@@                              114
        16777216 |                                         0

 disk I/O latency (ns)    /zones/zone01/root/ZONE01/oradata01         W                                              
          value  ------------- Distribution ------------- count
          524288 |                                         0
         1048576 |@@@@@@@                                  44
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@           202
         4194304 |@@@                                      519
         8388608 |                                         153
        16777216 |                                         0

 disk I/O latency (ns)    /zones/zone01/root/ZONE01/oradata03         W                                             
           value  ------------- Distribution ------------- count
          524288 |                                         0
         1048576 |@@@@@@@                                  968
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@           2309
         4194304 |@@@                                      528
         8388608 |                                         42
        16777216 |                                         0

 disk I/O latency (ns)    <none>                                      W                                             
           value  ------------- Distribution ------------- count
          524288 |                                         0
         1048576 |@@@@@@@@@@@                              913
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@             13482
         4194304 |@                                        418
         8388608 |                                         25
        16777216 |                                         0

 

 

Les résultats obtenus étaient correctes. Les IO physiques (lecture et écriture) se déroulaient dans des temps très convenables. Le problème ne se situait donc pas sur les baies. Donc dans le système... Mais où ? Je me suis donc plonger dans la lecture de "Solaris Internals" et "Configuring and Tuning Databases on the Solaris Platform" pour compendre ce qui se passait entre l'écriture demandée par Oracle (usermode) et l'écriture sur le device (IO physique). J'imaginais qu'il y avait un lock mais lequel ?

 

Une chose s'est révélée intéressante : les "Reader/Writer" locks (voir chapitre 17.6 dans "Solaris Internals"). Un seul thread à la fois peut accéder en écriture à un fichier. Voilà quelque chose de fort intéressant... J'ai donc écrit un petit script Dtrace en utilisant la probe lockstat (spécifiquement rw-block) pour obtenir les temps d'attente pour ce type de lock.

 

# cat rwlock.d
#!/usr/sbin/dtrace -Cs

#pragma D option quiet

lockstat::rw_enter:rw-block
/execname == "oracle" && arg1 > 1000000000 && zonename == "zone01"/

{
          printf("%Y %20s %8d %12d %12d %12d",walltimestamp,execname,pid,tid,arg1,arg2);
}

 

# ./rwlock.d
2011 Jul 21 00:01:13     oracle    21289       223   4238043920        0
2011 Jul 21 00:01:13     oracle    21289        88   4628837600        0
2011 Jul 21 00:01:13     oracle    21289       212   4351952245        0
2011 Jul 21 00:01:13     oracle    21289       238   4929624480        0
[...]

2011 Jul 21 00:01:18     oracle    21289       208   8635095680        0
[...]

2011 Jul 21 00:01:20     oracle    21289       195  12103783200        0
2011 Jul 21 00:01:20     oracle    21289       235  11806798240        0
2011 Jul 21 00:01:20     oracle    21289        43  11860924640        0
^C
2011 Jul 21 00:01:21     oracle    21289       226  13598520640        0
2011 Jul 21 00:01:21     oracle    21289        26  13602492640        0
2011 Jul 21 00:01:21     oracle    21289        46  13493121680        0
2011 Jul 21 00:01:21     oracle    21289        56  13310176960        0
2011 Jul 21 00:01:21     oracle    21289        64  13236565680        0
2011 Jul 21 00:01:21     oracle    21289        73  13197836080        0
2011 Jul 21 00:01:21     oracle    21289        75  13198641840        0
2011 Jul 21 00:01:21     oracle    21289        76  13199566320        0
2011 Jul 21 00:01:21     oracle    21289        71  12498137520        0

 

J'obtenais des "Writer" Locks supérieurs à 12 secondes !!! J'ai donc décicidé de faire tourner ces deux petits scripts (rwlock.d et aiowait.d) en même temps afin de voir si mes soupçons étaient corrects. Et bingo... Lors d'un message "WARNING: aiowait timed out", la somme des temps pour les "Writer Locks" était supérieur à 10 minutes (certains "Writer Lock" dépassaient 1 minute).

 

Mon gros soucis avec cette analyse était la suivante. J'avais la conviction que le soucis se situer sur ce type de lock mais impossible de l'affirmer. En effet, l'analyse s'avère exact si et seulement si il s'agit du même fichier qui est accéder. J'ai donc demandé au support Oracle système de me fournir un script Dtrace pouvant m'indiquer à la fois le type de lock "Reader/Writer", le temps de lock mais surtout le nom du fichier sur lequel le lock attendait. Le script fournit par le support - un grand Merci à Alexandre et Alain - nous a permis de mettre en relation l'alerte Oracle "WARNING: aiowait timed out" avec le nom du fichier (le plus souvent les fichiers undo et les tempfiles). 

 

Résumons la situation : des temps IO vu d'Oracle dépassant les 10 minutes, des IO physiques inférieurs à 30 millisecondes, des "Writers Locks" dépensant la minutes... ???!!! Lors d'une demande d'écriture sur un fichier, le système vérifie si le fichier est déjà accédé, si celui-ci est accédé alors il place cette demande dans une queue de type turnstile. Une fois la ressource disponible (ici le fichier) l'écriture physique peut s'effectuer. Lors d'une forte activité d'écriture sur un fichier, toutes les demandes s'empilent dans la queue. La dernière requête de la queue prendra donc un certains à se réaliser (c'est une FIFO). Il s'agit du mode fonctionnement POSIX d'un système de fichiers (UFS, VxFS, TMPFS).

 

Comment contourner ce problème ? Plusieurs solutions possibles : l'une d'elles est d'augmenter le nombre de fichiers (pour nous il s'agissait des fichiers undo et tempfiles). En augmentant le nombre de fichiers on augmente le nombre de queues (donc moins de locks par queue). L'autre solution consite à passer les systèmes de fichiers en accès directio. En effet le mode directio supprime les "Reader/Writer" locks : la couche applicative se débrouille pour gérer les accès concurents aux fichiers. Les bases de données Oracle savent très bien le faire (quelques infos dans cette article). Mais voilà, le passage en directio supprime certes ces locks mais supprime aussi l'effect du "cache filesystem". Toutes les lectures s'effectueront directement sur les disques physiques (pour pallier à ce problème il faut augmenter impérativement les SGA de vos bases de données).

 

Un sacré problème réglé...

 

P.S. : c'est pas évident d'être clair, n'hésitez pas à me demander des informations supplémentaires sur ces aspects. Je tiens à le souligner encore mais sans un outil comme Dtrace (n'oublions pas mdb) ce type d'analyse est pratiquement impossible. Un grand merci au support Oracle (base de données et système) pour toute l'aide apporté à la résolution de ce problème.

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

Mercredi 17 août 2011 3 17 /08 /Août /2011 20:26

 

Même si je ne pratique pas depuis longtemps dans le monde Unix (un peu plus de 10 ans) c'est l'une des 1er fois où je rencontre un cas de "Hard Swapping" sous Solaris. Situons un peu le contexte : depuis plusieurs jours un serveur sous Solaris 10 se retrouvait pratiquement tous les jours sur le prompt avec aucun message d'erreur (console et système). Malgrè la mise à jour corrective de l'OBP, rien n'y faisait, le serveur continuait à se retrouver continuellement sur le prompt. En intervenant par hasard sur un autre problème, j'ai intercepté une alerte provenant de ce fameux serveur "serveur non joignable".

 

L'examen via le déport m'indiquait aucune anomalie : alimentation, aucun message à la console, aucune interruption hard. La console répondait bizarrement aux commandes mais aucune réponse du système... Hop un petit break et une génération d'un petit core au passage histoire d'analyser un peu tout ça. Mon expérience dans ce type de cas m'oriente généralement vers un problème de "Swapping".

 

Je commence par vérifier ce que contenait mes queues CPU lors du crash...


# mdb -k 0

>
> ::cpuinfo
ID ADDR        FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD      PROC
  0 30003990000  1d    7    0  98  yes    no t-134  2a100781ca0 pageout
  1 30003994000  1d    2    6  -1   no    no t-0    2a100629ca0 (idle)
  2 30003998000  1d    1    0  -1   no    no t-0    2a100679ca0 (idle)
  3 0000183a628  1b    7    0 165  yes    no t-11   2a100047ca0 sched

 

C'est vraiment intéressant cette fonction pageout()... Cela confirme mon soupçon sur un problème provoqué par du "swapping"


> 30003990000::cpuinfo -v

 ID ADDR        FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD      PROC
  0 30003990000  1d    7    0  98  yes    no t-134  2a100781ca0 pageout
                  |    |
       RUNNING <--+    +-->  PRI THREAD      PROC
      QUIESCED                60 30008786380 cron
        EXISTS                60 30004861c20 aws_orb
        ENABLE                60 3000e307840 nsrexecd
                              60 300052d41c0 java 
                              60 3000539d0c0 inetd
                              60 300052d8200 svc.configd
                              60 30007789ae0 dataserver

 

Regardons de plus près ce que la cpu "id 3" tentait de faire

 

> 0000183a628::cpuinfo -v
ID ADDR        FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD      PROC
  3 0000183a628  1b    7    0 165  yes    no t-11   2a100047ca0 sched
                  |    |    |
       RUNNING <--+    |    +--> PIL THREAD
         READY         |           6 2a100047ca0
        EXISTS         |           - 2a100751ca0 pageout
        ENABLE         |
                       +-->  PRI THREAD      PROC
                              60 30008784360 cron
                              60 30007164760 adclient
                              60 30007fa1c40 dataserver
                              60 30005128400 python
                              60 3000dcc8b00 java
                              60 3000d7b9280 aws_sadmin
                              60 30003b563e0 naviagent

> 2a100751ca0::threadlist -v
            ADDR             PROC              LWP CLS PRI            WCHAN000002a100751ca0      60027254468                0   0  97                0

  PC: ktl0+0x48    THREAD: pageout_scanner()
  stack pointer for thread 2a100751ca0: 2a100750f91
  [ 000002a100750f91 ktl0+0x48() ]
    checkpage+0x78()
    pageout_scanner+0x3f4()
    thread_start+4()

 

Le "Page scanner" est bien en cours de fonctionnement (voir sched.c). Vérifions un peu les valeurs liées aux "Swapping".


> avefree/E

avefree:
avefree:          2871
> minfree/E
minfree:
minfree:          8029
> freemem/E
freemem:
freemem:          2888
> needfree/E
needfree:
needfree:        18322
> freemem_wait/D
freemem_wait:
freemem_wait:      426

 

Pour le coup le rapport avefree < minfree est avéré... confirmation de mon hypothèse... On ne dispose plus beaucoup de pages libre (freemem) et le nombre de thread en attente est de 426 (freemem_wait). Voir dans le code vm_page.c pour les explications.

 

Nous sommes donc en présence d'un cas de "Hard Swapping". Ce mode est beaucoup plus agressif que le "Soft Swapping". Une fois activé l'algorithme peut décider de unloader un module kernel non utilisé pour libérer des pages mémoires. Ce qui explique que mon serveur ne répondait plus...

 

> ::modinfo !grep ip
 58         7b600000   144040   1 ip (IP STREAMS driver 1.47)
 82         7bb61cd8      590   1 ip6 (IP6 STREAMS driver 1.9)
146                0        0   0 ipsecesp (?)
147                0        0   0 ipsecah (?)
200                0        0   0 ippctl (?)
223         7afcc000     83a8   1 fcip (SunFC FCIP v20091105-1.50)
242         7aa42000    2dd90   1 ipf (IP Filter: v4.1.9)
253         7b7f8d38     1300   1 ipc (common ipc code)

 

Pour les habitués il manque le "module ip". Petite vérification sur le serveur en fonctionnement


# modinfo | grep ip

58 7b600000 144040   3   1  ip (IP STREAMS driver 1.47)
58 7b600000 144040   -   1  ip (IP STREAMS module 1.47)
[. . .] 

 

J'ai réussi à mettre en pratique un cas rare que j'avais étudié il y a déjà quelques temps. Faut dire des problèmes de "Swapping" sur les infras actuelles sont de plus en plus rare. Pour les mordus de lecture, je vous renvois au chapitre 10 de "Solaris Internals".

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

Dimanche 14 août 2011 7 14 /08 /Août /2011 15:32

 

Je vais m'intéresser ici uniquement au cache filesystem, pour ceux qui souhaitent comprendre le fonctionnement globale de la mémoire je vous renvoie à la présentation de William Roche effectuée lors d'une des nombreuses soirée Guses. Il ne s'agit pas ici d'expliquer précisemment le fonctionnement de ce cache, pour les puristes je vous renvois aux excellents ouvrages "Solaris Internals" et "Solaris Performance and tools".

 

Le cache filesystem a été implémenté comme une partie intégrante de la mémoire virtuelle depuis la version de SunOS 4.0. Il permet d'utiliser dynamiquement l'ensemble de la mémoire disponible pour cacher les fichiers en mémoire RAM (découper en page). L'intérêt est important : éliminer les IO physiques. Le cache filesystem s'intégre automatiquement quelque soit le système de fichiers utilisé (fonctionne avec UFS, NFS, VxFS, a noter qu'avec ZFS son fonctionnement apporte son petit lot de différences).

 

Pour visulaliser l'utilisation de la mémoire j'utilise souvent la macro memstat. Cette macro permet de cerner rapidement comment la mémoire RAM du système Solaris est découpée.

 

# mdb -k
Loading modules: [ unix genunix specfs dtrace zfs sd pcisch ssd fcp fctl mpt emlxs ip hook neti mpt_sas sctp arp usba s1394 wrsm nca lofs md cpc random crypto wrsmd fcip logindmux ptm ufs sppp nfs ipc ]

> ::memstat

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     832396              6503    8%
ZFS File Data             2106285             16455   20%
Anon                      4334797             33865   42%
Exec and libs               24420               190    0%
Page cache                 342936              2679    3%
Free (cachelist)          2563444             20026   25%
Free (freelist)             88904               694    1% 

Total                    10293182             80415
Physical                 10269991             80234


Le cache filesystem est composé des deux éléments suivants "Page cache" et "Free (cachelist)". Pour simplifier, la catégorie "Page cache" inclue la portion "segmap" (inclus aussi les fichiers mappés). Quand un fichier est accédé (lecture ou écriture) celui-ci est placé dans la portion "segmap". Le fichier peut être par la suite placé dans la portion "Free (cachelist)" (pour plus de détails techniques sur le fonctionnement de segmap et du cache filesystem je vous renvois au chapitre 14.7 et 14.8 dans "Solaris Internals").

 

De nombreux outils inclus dans le système nous permettent de vérifier l'activité du cache filesystem. La commande vmstat fait partie de ces outils. La colonne "re" indique le nombre de page transféré entre la portion "Free (cachelist)" et la portion "segmap". La colonne "fpi" indique le nombre de lecture (en kb) de "fichiers réguliers" entre le disque et le cache filesystem (pour plus d'explication n'oublier pas de lire le manuel de la commande).     

 

# vmstat -p 3 5
     memory           page          executable      anonymous      filesystem
   swap  free  re  mf  fr  de  sr  epi  epo  epf  api  apo  apf  fpi  fpo  fpf
76804104 18206496 5744 5392 218 0 0 105  0    0    0    0    0 45998 218  218
83421912 26518528 868 223 0 0  0    0    0    0    0    0    0 6315    0    0
83421728 26526200 1624 503 8 0 0    0    0    0    0    0    0 6647    8    8
83423152 26536064 1159 458 0 0 0    0    0    0    0    0    0 5539    0    0
83421648 26538952 1002 1333 0 0 0   0    0    0    0    0    0 6738    0    0

 

Avec Dtrace il est possible d'en savoir un peu plus. Par exemple je peux savoir qui provoque cette activité de paging disque vers mémoire, qui provoque une activité "Free (cachelist)" vers "Page cache", etc... Les deux commandes suivantes nous le montre rapidement.

 

# dtrace -n 'vminfo:::fspgin { @[execname] = count(); }'
dtrace: description 'vminfo:::fspgin ' matched 1 probe
^C 

  rsync            20

# dtrace -n 'vminfo:genunix::pgrec { @[execname] = count(); }'
dtrace: description 'vminfo:genunix::pgrec ' matched 1 probe
^C 

  oracle          108 

 

Ce qui est surtout intéressant c'est de calculer le bénéfice qu'offre le cache filesystem. Je calcule ici le nombre d'opérations de lecture dans le cache et sur le disque. Pour ce faire j'utilise comme toujours Dtrace. Deux probes sont nécessaires : la probe "fsinfo" (activités du filesystem) et la probe "io" (activités des io physiques). Petite spécificité du script, je recherche uniquement des opérations des bases de données Oracles (chaque base étant dans une zone Solaris).

 

# cat cacheread.d

#!/usr/sbin/dtrace -s
#pragma D option quiet

dtrace:::BEGIN
{
        trace("Tracing for 60 minutes... Ctrl-C to quit.\n\n");
}

fsinfo:::read
/execname == "oracle"/
{
        @io["logical", zonename] = count();
}

io:::start
/args[0]->b_flags & B_READ && execname == "oracle"/
{
        @io["physical", zonename] = count();
}

profile:::tick-60m
{
        printa(" %-10s %-10s %10@d\n", @io);
        trunc(@io);
        exit(0);
}


# ./cacheread.d

Tracing for 60 minutes... Ctrl-C to quit.
^C
  physical      zone10             2022
  logical       zone10            45419 

 

Le résultat parle de lui même. 95% des lectures se sont effectuées en mémoire et non sur disque. L'accès à la mémoire étant nettement plus rapide que l'accès à un disque, le bénéficie est estimable (cela dépend en grande partie du type de workload de nos applications, je l'accorde). Cependant tout n'est pas si simple que cela... Dans un prochain article nous verrons un cas où son activation pose de réel problème.

 

P.S : Il existe une multitude de scripts Dtrace permettant de mesurer l'efficacité du cache filesystem : par exemple readtype.d, writetype.d, etc...

 

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

Lundi 8 août 2011 1 08 /08 /Août /2011 21:37

 

Comment vérifier le mode d'accès directio sur nos fichiers ? Confronté récemment à cette question, je vous livre ici une des manières d'y répondre. A noter l'utilisation d'UFS dans mon cas.

 

Il existe deux implémentations du directio pour UFS :

  • Option de montage du système de fichiers
  • Modification du flag de l'inode pour un fichier ouvert

La 1er méthode est assez simple à vérifier alors que la 2ème si vous n'êtes pas en train de vérifier l'appel ioctl() au moment ou celui-ci se produit il est plus difficile de le vérifier (je vous renvois à l'article suivant pour plus de précision). Reste la possibilité d'utiliser dtrace mais encore faut'il que le fichier soit accéder pour le savoir.

 

Bon passons un peu aux manipulations... Avec dtrace on peut utiliser la ligne suivante et attendre (longtemps... très longtemps)


# dtrace -qn fbt:ufs:directio_start:entry { printf("%d %s", pid, stringof(args[1]-›i_vnode-›v_path)); }

21350 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_crontrol_02.ctl
21350 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_crontrol_01.ctl
^C


Ici le process 21350 accède aux fichiers control* avec le mode d'accès directio. Vérifions maintenant dans le kernel ce qui s'y passe vraiment.

 

# sudo mdb -k
Loading modules: [ unix genunix specfs dtrace zfs sd pcisch ssd fcp fctl mpt emlxs ip mpt_sas hook neti sctp arp usba s1394 wrsm nca lofs md cpc wrsmd fcip random crypto logindmux ptm ufs sppp nfs ipc ]
> 0t21350::pid2proc
3021bbcd3e0
 3021bbcd3e0::pfiles !grep control
 256  REG 000003009dacc2c0 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_01.ctl
 257  REG 000003006520e300 /zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_02.ctl

> 000003009dacc2c0::print vnode_t

{
    v_lock = {
        _opaque = [ 0 ]
    }
    v_flag = 0x10000
    v_count = 0x5
    v_data = 0x30127d14d10
    v_vfsp = 0x60063e12040
    v_stream = 0
    v_type = 1 (VREG)
    v_rdev = 0xffffffffffffffff
    v_vfsmountedhere = 0
    v_op = 0x6006883ed80
    v_pages = 0
    v_npages = 0
    v_msnpages = 0
    v_scanfront = 0
    v_scanback = 0
    v_filocks = 0x3002740bd40
    v_shrlocks = 0
    v_nbllock = {
        _opaque = [ 0 ]
    }
    v_cv = {
        _opaque = 0
    }
    v_locality = 0
    v_femhead = 0
    v_path = 0x300adca6020 "/zones/zone01/root/ZONE01/oradata13/XXXG02/xxxg02_control_01.ctl"
    v_rdcnt = 0x4
    v_wrcnt = 0x4
    v_mmap_read = 0
    v_mmap_write = 0
    v_mpssdata = 0
    v_scantime = 0
    v_mset = 0
    v_msflags = 0
    v_msnext = 0                     
    v_msprev = 0
    v_mslock = {
        _opaque = [ 0 ]
    }
}

 

Comme évoqué plus haut, il y a deux implémentations possibles pour le directio. Soit le montage du système de fichiers posséde l'option directio (man mount_ufs), soit le flag de l'inode (voir ufs_inode.h).

 

Vérifions l'une et l'autre dans le kernel :

 

> 0x60063e12040::fsinfo -v
            VFSP FS              MOUNT
0000060063e12040 ufs             /zones/zone01/root/ZONE01/oradata13
              R: /dev/vx/dsk/zone01/oradata13
              O: rw,intr,largefiles,logging,noquota,xattr,nodfratime,onerror=panic

 

Nous voyons dans les options de montage qu'il ne sagit pas de la 1er méthode d'implémentation. Voyons la suivante :

 

> 0x30127d14d10::print inode_t !grep i_flag
    i_flag = 0x4260

 

Le flag pour cette inode possède bien le masque directio (0x4000). Suite à l'ouverture du fichier open(), l'application (ici une base de données Oracle) a modifié le mode d'accès directio par l'appel ioctl().

 

A vous de jouer pour vérifier directement dans le kernel, le mode d'accès directio à tous vos fichiers. Dans un prochain article je reviendrai sur ce mode (son fonctionnement, pourquoi l'utiliser, exemple d'un problème de performance).

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

Dimanche 7 août 2011 7 07 /08 /Août /2011 20:34

 

Le 5 avril dernier (cela remonte déjà à quelques temps...), Oracle a organisé en collaboration avec le groupe Guses l'événèment suivant : Tech Day Solaris. Pour toutes les personnes n'ayant pas pu participer à cet évènement, vous trouverez sur mon blog toutes les présentations effectuées lors de cette journée.

 

Un grand merci à Cyril Galibern pour son retour d'expérience sur l'utilisation des containers Solaris 10 (l'utilisation des containers Solaris est géré par son outils OpenSVC : je vous invite à le découvrir si vous ne le connaissez pas).

Par gloumps - Publié dans : divers - Communauté : Solaris et OpenSolaris
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

Novembre 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
             
<< < > >>
Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Signaler un abus - Articles les plus commentés