Existe-t-il un moyen d'obtenir des ratios Cache Hit / Miss pour les périphériques de blocs sous Linux?

Est-il possible de voir sous Linux combien de requêtes de lecture et d'écriture à partir de l'espace utilisateur finissent par provoquer des occurrences et des échecs de cache pour les périphériques de bloc?

Vous pouvez développer votre propre script SystemTap . Vous devez tenir compte des deux sous-systèmes suivants:

• VFS: cela représente toutes les demandes d'E / S avant le cache tampon (c'est-à-dire absolument toutes les demandes 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 par leur numéro majeur + mineur respectif.
• Bloquer: cela représente toutes les demandes d'E / S envoyées aux périphériques de bloc avant le planificateur d'E / S (qui fusionne également + réordonne les demandes d'E / S); ici, nous savons quelles demandes ont été manquées par le cache du tampon; consultez la sonde "ioblock.request".

Le développement de SystemTap prend un certain temps à apprendre. Si vous êtes un développeur modéré et que vous 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 de stock le supportent aujourd'hui. Vous devrez également installer les symboles de débogage pour votre noyau. Pour mon système Ubuntu, cela a été 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. Cela est expliqué sur la page Wiki SystemtapOnUbuntu , par exemple.

PS N'utilisez 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.

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
}

/ 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). Pour autant que je sache, il n'y a aucun moyen d'extraire ces informations particulières du noyau, bien qu'il ne devrait pas être très difficile d'écrire un peu de code à faire.

Modifier: http://www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html

Il y a maintenant l' utilitaire cachestat du paquet perf-tools .

L'auteur énumère également quelques alternatives (peut-être plus grossières) que les gens utilisent:

A) Étudiez le taux d'échec du cache de page en utilisant iostat (1) pour surveiller les lectures de disque, et supposez qu'il s'agit d'échecs de cache, et non, par exemple, O_DIRECT. Le taux d'échecs est généralement une mesure plus importante que le rapport, car les échecs sont proportionnels à la douleur d'application. Utilisez également free (1) pour voir les tailles de cache.

B) Supprimez le cache de page (echo 1> / proc / sys / vm / drop_caches) et mesurez la dégradation des performances! J'adore l'utilisation d'une expérience négative, mais c'est bien sûr un moyen douloureux de faire la lumière sur l'utilisation du cache.

C) Utilisez sar (1) et étudiez les défauts mineurs et majeurs. Je ne pense pas que cela fonctionne (par exemple, des E / S régulières).

D) Utilisez le script SystemTap cache-hit-rate.stp, qui est le numéro deux dans une recherche Internet pour le taux d'accès au cache de page 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 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".

Si vous êtes intéressé par le rapport IO hit / miss d'un processus spécifique, une approche simple mais très efficace consiste à lire le /proc/<pid>/iofichier.

Vous trouverez ici 4 valeurs clés:

• rchar: le nombre total d'octets de lecture du point de vue de l' application (c'est-à-dire sans différence entre la lecture satisfaite du stockage physique plutôt que du cache)
• wchar: comme ci-dessus, mais sur les octets écrits
• read_bytes: les octets lisent vraiment depuis le sous-système de stockage
• write_bytes: les octets vraiment écrits dans le sous-système de stockage

Supposons qu'un processus ait les valeurs suivantes:

rchar: 1000000
read_bytes: 200000

Le taux d'échec du cache de lecture (en octets) est 100*200000/1000000 = 20%, et le taux de réussite est100-20 = 80%

Cependant, il y a un hic: la rcharvaleur inclut la chose comme tty IO, donc pour les processus qui lisent / écrivent beaucoup depuis / vers un tuyau, le calcul ci-dessus sera faussé, rapportant un taux de réussite plus élevé que le taux effectif.