¿Hay alguna manera de obtener las proporciones Hit / Miss Cache para dispositivos de bloque en Linux?

¿Es posible ver en Linux cuántas solicitudes de lectura y escritura desde el espacio de usuario terminan causando aciertos y errores de caché para dispositivos de bloque?

Puede desarrollar su propio script SystemTap . Debe tener en cuenta los siguientes dos subsistemas:

• VFS: esto representa todas las solicitudes de E / S antes de la memoria caché del búfer (es decir, absolutamente todas las solicitudes de E / S); revise las sondas "vfs.read", "vfs.write" y "kernel.function (" vfs_ * ")"; necesita filtrar los dispositivos de bloque que desea monitorear por sus respectivos números mayores + menores.
• Bloque: representa todas las solicitudes de E / S enviadas a los dispositivos de bloque antes del planificador de E / S (que también combina + reordena las solicitudes de E / S); aquí sabemos qué solicitudes fueron perdidas por el caché de Buffer; revise la sonda "ioblock.request".

El desarrollo de SystemTap lleva algo de tiempo para aprender. Si es un desarrollador moderado y tiene un buen conocimiento de Linux, debería hacerlo en 3-4 días. Sí, lleva tiempo aprender, pero estará muy contento con los resultados: SystemTap le brinda la oportunidad de colocar (de forma segura) las sondas en casi cualquier lugar del kernel de Linux.

Tenga en cuenta que su núcleo debe tener soporte para cargar y descargar módulos del núcleo. La mayoría de los núcleos en existencia hoy en día lo admiten. También necesitará instalar los símbolos de depuración para su núcleo. Para mi sistema Ubuntu, esto fue tan fácil como descargar varios cientos de MB .deb, que el equipo de desarrollo del kernel de Ubuntu compiló para mí. Esto se explica en la página Wiki SystemtapOnUbuntu , por ejemplo.

PD Tome el enfoque de SystemTap solo si no tiene otra solución, porque es un marco totalmente nuevo que debe aprender, y que cuesta tiempo / dinero y, a veces, frustración.

Seguí adelante y escribí un script stap para esto. Hay uno en el wiki de systemtap, pero no parece ser correcto. En las pruebas básicas, esto parece bastante preciso, pero 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 es un buen comienzo, pero no le brinda toda la información que está buscando (no se deje engañar por los porcentajes de aciertos / errores en sistemas con múltiples núcleos y estadísticas habilitados; eso es otra cosa). Hasta donde sé, no hay una manera de extraer esa información en particular del núcleo, aunque no debería ser terriblemente difícil escribir un poco de código.

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

Ahora está la utilidad cachestat del paquete perf-tools .

El autor también enumera algunas alternativas (posiblemente más crudas) que las personas usan:

A) Estudie la tasa de pérdida de memoria caché de la página utilizando iostat (1) para monitorear las lecturas de disco, y suponga que se trata de errores de memoria caché y no, por ejemplo, O_DIRECT. La tasa de fallas generalmente es una métrica más importante que la relación de todos modos, ya que las fallas son proporcionales al dolor de la aplicación. También use free (1) para ver los tamaños de caché.

B) Elimine el caché de la página (echo 1> / proc / sys / vm / drop_caches) y mida cuánto empeora el rendimiento. Me encanta el uso de un experimento negativo, pero esta es, por supuesto, una forma dolorosa de arrojar algo de luz sobre el uso de caché.

C) Use sar (1) y estudie fallas menores y mayores. No creo que esto funcione (p. Ej., E / S regulares).

D) Utilice el script cache-hit-rate.stp SystemTap, que es el número dos en una búsqueda en Internet para la proporción de aciertos de caché de página de Linux. Instrumenta el acceso a la memoria caché en la parte superior de la pila, en la interfaz VFS, para que se puedan ver las lecturas en cualquier sistema de archivos o dispositivo de almacenamiento. Las pérdidas de caché se miden a través de su E / S de disco. Esto también pierde algunos tipos de carga de trabajo (algunos se mencionan en "Lecciones" en esa página), y llama a las proporciones "tasas".

Si está interesado en la relación IO hit / miss de un proceso específico, un enfoque simple pero muy efectivo es leer el /proc/<pid>/ioarchivo.

Aquí encontrará 4 valores clave:

• rchar: el número total de bytes de lectura desde el punto de vista de la aplicación (es decir, sin diferencia entre la lectura satisfecha desde el almacenamiento físico en lugar de la memoria caché)
• wchar: como arriba, pero sobre bytes escritos
• read_bytes: los bytes realmente leen del subsistema de almacenamiento
• write_bytes: los bytes realmente escritos en el subsistema de almacenamiento

Digamos que un proceso tiene los siguientes valores:

rchar: 1000000
read_bytes: 200000

El índice de pérdida de caché de lectura (en bytes) es 100*200000/1000000 = 20%, y el índice de aciertos es100-20 = 80%

Sin embargo, hay un problema: el rcharvalor incluye algo como tty IO, por lo que para los procesos que leen / escriben mucho desde / hacia una tubería, el cálculo anterior será sesgado, informando una relación de aciertos más alta que la efectiva.