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

Soluzione 1:

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

• VFS:questo rappresenta tutte le richieste di I/O prima della Buffer cache (cioè assolutamente ogni richiesta di I/O); rivedere i probe "vfs.read", "vfs.write" e "kernel.function("vfs_*")"; è necessario filtrare i dispositivi a blocchi che si desidera monitorare in base ai rispettivi numeri maggiore+minore.
• Block:rappresenta tutte le richieste di I/O inviate ai dispositivi a blocchi prima dello scheduler di I/O (che esegue anche merge + riordino delle richieste di I/O); qui sappiamo quali richieste sono state perse dalla Buffer cache; rivedere il probe "ioblock.request".

Lo sviluppo di SystemTap richiede del tempo per imparare. Se sei uno sviluppatore moderato e hai una buona conoscenza di Linux, dovresti aver finito in 3-4 giorni. Sì, ci vuole tempo per imparare, ma sarai molto soddisfatto dei risultati:SystemTap ti offre l'opportunità di inserire (in modo sicuro) i probe in quasi tutti i punti del kernel Linux.

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

P.S. Prendi 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.

Soluzione 2:

Sono andato avanti e ho scritto una sceneggiatura stap 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
}

Soluzione 3:

/proc/slabinfo è un buon inizio, ma non ti fornisce esattamente 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'è un modo per estrarre quella particolare informazione dal kernel, anche se non dovrebbe essere terribilmente difficile scrivere un po' di codice da fare.

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

Soluzione 4:

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

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

A) Studia il tasso di errori nella cache delle pagine utilizzando iostat(1) per monitorare le letture del disco e supponi che si tratti di errori nella cache e non, ad esempio, O_DIRECT. Il tasso di errori è comunque una metrica più importante del rapporto, poiché gli errori 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 quanto peggiorano le prestazioni! Adoro l'uso di un esperimento negativo, ma questo è ovviamente un modo doloroso per far luce sull'utilizzo della cache.

C) Usare sar(1) e studiare gli errori minori e maggiori. Non penso che funzioni (ad es. I/O regolari).

D) Usa lo script cache-hit-rate.stp SystemTap, che è il numero due in una ricerca su Internet per la percentuale di riscontri della cache della pagina Linux. Strumenta l'accesso alla cache in alto nello stack, nell'interfaccia VFS, in modo da poter vedere le letture su qualsiasi file system o dispositivo di archiviazione. I mancati riscontri nella cache vengono misurati tramite il loro I/O su disco. In questo mancano anche alcuni tipi di carico di lavoro (alcuni sono menzionati in "Lezioni" in quella pagina) e chiama i rapporti "tariffe".