Esiste un modo per ottenere i rapporti Cache Hit / Miss per i dispositivi a blocchi in Linux?

È possibile vedere in Linux quante richieste di lettura e scrittura dallo spazio utente finiscono per causare hit e mancate cache per i dispositivi a blocchi?

Puoi sviluppare il tuo script SystemTap . È necessario tenere conto dei due sottosistemi seguenti:

• VFS: rappresenta tutte le richieste I / O prima della cache del buffer (ovvero assolutamente ogni richiesta I / O); rivedere le sonde "vfs.read", "vfs.write" e "kernel.function (" vfs_ * ")"; è necessario filtrare i dispositivi a blocchi che si desidera monitorare in base ai rispettivi numeri maggiori + minori.
• Blocco: rappresenta tutte le richieste I / O inviate ai dispositivi a blocchi prima dello scheduler I / O (che inoltre unisce + riordina le richieste I / O); qui sappiamo quali richieste sono state perse dalla cache del buffer; rivedere la sonda "ioblock.request".

Lo sviluppo di SystemTap richiede del tempo per imparare. Se sei uno sviluppatore moderato e hai una buona conoscenza di Linux, dovresti farlo in 3-4 giorni. Sì, ci vuole tempo per imparare, ma sarai molto contento dei risultati - SystemTap ti dà l'opportunità di mettere (in modo sicuro) i probe in quasi ogni posto nel kernel di Linux.

Nota che il tuo kernel deve avere supporto per il caricamento e lo scaricamento dei moduli del kernel. La maggior parte dei kernel di stock al giorno d'oggi supporta questo. Dovrai anche installare i simboli di debug per il tuo kernel. Per il mio sistema Ubuntu, questo è stato facile come scaricare un file .deb di diverse centinaia di MB, che il team di sviluppo del kernel Ubuntu ha compilato per me. Questo è spiegato alla pagina Wiki SystemtapOnUbuntu , per esempio.

PS Adotta l'approccio SystemTap solo se non hai altra soluzione, perché è un framework totalmente nuovo che devi imparare e che costa tempo / denaro e talvolta frustrazione.

Sono andato avanti e ho scritto una sceneggiatura per questo. Ce n'è uno sul wiki di systemtap, ma non sembra essere corretto. Nei test di base, questo sembra abbastanza accurato ma 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 è un buon inizio, ma non ti dà abbastanza le informazioni che stai cercando (non lasciarti ingannare dalle percentuali di hit / miss su sistemi con più core e statistiche abilitate; quelli sono qualcos'altro). Per quanto ne so, non c'è modo di estrarre dal kernel quelle informazioni particolari, anche se non dovrebbe essere tremendamente difficile scrivere un po 'di codice da fare.

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

Ora c'è l' utilità cachestat dal pacchetto perf-tools .

L'autore elenca anche alcune alternative (forse più grossolane) che le persone usano:

A) Studiare la percentuale di errori nella cache della pagina utilizzando iostat (1) per monitorare le letture del disco e supporre che si tratti di errori nella cache e non, ad esempio, O_DIRECT. Il tasso di insuccesso è di solito comunque una metrica più importante del rapporto, poiché gli insuccessi sono proporzionali al dolore dell'applicazione. Usa anche free (1) per vedere le dimensioni della cache.

B) Rilascia la cache della pagina (echo 1> / proc / sys / vm / drop_caches) e misura quante prestazioni peggiorano! Adoro l'uso di un esperimento negativo, ma questo è ovviamente un modo doloroso per fare luce sull'uso della cache.

C) Usa sar (1) e studia i difetti minori e maggiori. Non penso che funzioni (ad es. I / O regolari).

D) Utilizzare lo script SystemTap cache-hit-rate.stp, che è il numero due in una ricerca su Internet per il rapporto di hit della cache delle pagine Linux. Strumenti di accesso alla cache in alto nello stack, nell'interfaccia VFS, in modo che sia possibile leggere qualsiasi file system o dispositivo di archiviazione. I fallimenti della cache vengono misurati tramite l'I / O del disco. Ciò manca anche di alcuni tipi di carico di lavoro (alcuni sono menzionati in "Lezioni" in quella pagina) e chiama i rapporti "tariffe".

Se sei interessato al rapporto I / O di un processo specifico, un approccio semplice ma molto efficace è leggere il /proc/<pid>/iofile.

Qui troverai 4 valori chiave:

• rchar: il numero totale di byte letti dal punto di vista dell'applicazione (es .: senza alcuna differenza tra lettura soddisfatta dalla memoria fisica piuttosto che dalla cache)
• wchar: come sopra, ma sui byte scritti
• read_bytes: i byte letti realmente dal sottosistema di archiviazione
• write_bytes: i byte realmente scritti nel sottosistema di archiviazione

Supponiamo che un processo abbia i seguenti valori:

rchar: 1000000
read_bytes: 200000

Il rapporto di missaggio della cache di lettura (in byte) è 100*200000/1000000 = 20%e il rapporto di hit è100-20 = 80%

C'è un problema, tuttavia: il rcharvalore include qualcosa come tty IO, quindi per i processi che leggono / scrivono molto da / verso una pipe il calcolo sopra sarà distorto, riportando un rapporto di hit più elevato di quello effettivo.