Solution 1 :
Vous pouvez développer votre propre script SystemTap. Vous devez comptabiliser les deux sous-systèmes suivants :
- VFS :cela représente toutes les requêtes d'E/S avant le cache tampon (c'est-à-dire absolument toutes les requêtes d'E/S) ; passez en revue les sondes "vfs.read", "vfs.write" et "kernel.function("vfs_*")" ; vous devez filtrer les périphériques de bloc que vous souhaitez surveiller en fonction de leurs numéros majeurs + mineurs respectifs.
- Bloc :cela représente toutes les requêtes d'E/S envoyées aux périphériques de bloc avant le planificateur d'E/S (qui fusionne et réorganise également les requêtes d'E/S) ; ici, nous savons quelles requêtes ont été manquées par le cache Buffer ; examinez la sonde "ioblock.request".
Le développement de SystemTap prend un certain temps à apprendre. Si vous êtes un développeur modéré et avez une bonne connaissance de Linux, vous devriez avoir terminé en 3-4 jours. Oui, cela prend du temps à apprendre, mais vous serez très satisfait des résultats - SystemTap vous donne la possibilité de placer (en toute sécurité) des sondes à presque n'importe quel endroit du noyau Linux.
Notez que votre noyau doit prendre en charge le chargement et le déchargement des modules du noyau. La plupart des noyaux d'origine le supportent aujourd'hui. Vous devrez également installer les symboles de débogage pour votre noyau. Pour mon système Ubuntu, c'était aussi simple que de télécharger un fichier .deb de plusieurs centaines de Mo, que l'équipe de développement du noyau Ubuntu a compilé pour moi. Ceci est expliqué sur la page Wiki SystemtapOnUbuntu, par exemple.
PS N'adoptez l'approche SystemTap que si vous n'avez pas d'autre solution, car c'est un cadre totalement nouveau que vous devez apprendre, et qui coûte du temps/de l'argent et parfois de la frustration.
Solution 2 :
Je suis allé de l'avant et j'ai écrit un script stap pour cela. Il y en a un sur le wiki systemtap, mais il ne semble pas être correct. Dans les tests de base, cela semble assez précis mais YMMV.
#! /usr/bin/env stap
global total_bytes, disk_bytes, counter
probe vfs.read.return {
if (bytes_read>0) {
if (devname=="N/A") {
} else {
total_bytes += bytes_read
}
}
}
probe ioblock.request
{
if (rw == 0 && size > 0)
{
if (devname=="N/A") {
} else {
disk_bytes += size
}
}
}
# print VFS hits and misses every 5 second, plus the hit rate in %
probe timer.s(5) {
if (counter%15 == 0) {
printf ("\n%18s %18s %10s %10s\n",
"Cache Reads (KB)", "Disk Reads (KB)", "Miss Rate", "Hit Rate")
}
cache_bytes = total_bytes - disk_bytes
if (cache_bytes < 0)
cache_bytes = 0
counter++
hitrate = 10000 * cache_bytes / (cache_bytes+disk_bytes)
missrate = 10000 * disk_bytes / (cache_bytes+disk_bytes)
printf ("%18d %18d %6d.%02d%% %6d.%02d%%\n",
cache_bytes/1024, disk_bytes/1024,
missrate/100, missrate%100, hitrate/100, hitrate%100)
total_bytes = 0
disk_bytes = 0
}
Solution 3 :
/proc/slabinfo est un bon début, mais ne vous donne pas tout à fait les informations que vous recherchez (ne vous laissez pas berner par les pourcentages de réussite/échec sur les systèmes avec plusieurs cœurs et statistiques activés ; ce sont autre chose). Autant que je sache, il n'y a aucun moyen d'extraire cette information particulière du noyau, bien qu'il ne soit pas très difficile d'écrire un peu de code à faire.
Modifier :http://www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html
Solution 4 :
Il y a maintenant l'utilitaire cachestat du paquet perf-tools.
L'auteur énumère également certaines alternatives (peut-être plus grossières) que les gens utilisent :
A) Étudiez le taux d'échecs du cache de pages en utilisant iostat(1) pour surveiller les lectures de disque et supposez qu'il s'agit d'échecs de cache et non, par exemple, de O_DIRECT. Le taux d'échec est généralement une mesure plus importante que le ratio de toute façon, puisque les échecs sont proportionnels à la douleur de l'application. Utilisez également free(1) pour voir les tailles de cache.
B) Supprimez le cache de la page (echo 1> /proc/sys/vm/drop_caches), et mesurez à quel point les performances se détériorent ! J'adore l'utilisation d'une expérience négative, mais c'est bien sûr un moyen pénible de faire la lumière sur l'utilisation du cache.
C) Utiliser sar(1) et étudier les défauts mineurs et majeurs. Je ne pense pas que cela fonctionne (par exemple, des E/S normales).
D) Utilisez le script cache-hit-rate.stp SystemTap, qui est le numéro deux dans une recherche Internet pour le taux d'accès au cache des pages Linux. Il instrumente l'accès au cache haut dans la pile, dans l'interface VFS, de sorte que les lectures sur n'importe quel système de fichiers ou périphérique de stockage peuvent être vues. Les échecs de cache sont mesurés via leurs E/S de disque. Cela manque également certains types de charge de travail (certains sont mentionnés dans "Leçons" sur cette page) et appelle les ratios "taux".