Overblog
Suivre ce blog
Editer l'article Administration Créer mon blog
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...

 

Partager cet article

Published by gloumps - dans kernel
commenter cet article

commentaires