Partager l'article ! Comprendre et vérifier l'utilisation du cache filesystem: Je vais m'intéresser ici uniquement au cache filesystem, pour ceux q ...
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);
}
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...
| Juin 2012 | ||||||||||
| 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 | |||||
|
||||||||||