Existe uma maneira de obter taxas de Acertos / Perdas de Cache para dispositivos de bloco no Linux?

É possível ver no Linux quantas solicitações de leitura e gravação do espaço do usuário acabam causando acertos e falhas no cache de dispositivos de bloco?

Você pode desenvolver seu próprio script SystemTap . Você precisa considerar os dois subsistemas a seguir:

• VFS: representa todas as solicitações de E / S antes do cache do buffer (ou seja, absolutamente todas as solicitações de E / S); revise as análises "vfs.read", "vfs.write" e "kernel.function (" vfs_ * ")" "; você precisa filtrar os dispositivos de bloco que deseja monitorar pelos respectivos números principais + secundários.
• Bloco: representa todas as solicitações de E / S enviadas aos dispositivos de bloco antes do agendador de E / S (que também mescla + reordena as solicitações de E / S); aqui sabemos quais solicitações foram perdidas pelo cache do buffer; revise o probe "ioblock.request".

O desenvolvimento do SystemTap leva algum tempo para aprender. Se você é um desenvolvedor moderado e possui bons conhecimentos em Linux, isso deve ser feito em 3 a 4 dias. Sim, leva tempo para aprender, mas você ficará muito feliz com os resultados - o SystemTap oferece a oportunidade de colocar (com segurança) sondas em praticamente qualquer lugar do kernel do Linux.

Observe que seu kernel deve ter suporte para carregar e descarregar módulos do kernel. Atualmente, a maioria dos núcleos de estoque suporta isso. Você também precisará instalar os símbolos de depuração para o seu kernel. Para o meu sistema Ubuntu, isso foi tão fácil quanto o download de um arquivo .deb de várias centenas de MB, que a equipe de desenvolvimento do kernel do Ubuntu compilou para mim. Isso é explicado na página Wiki do SystemtapOnUbuntu , por exemplo.

PS Adote a abordagem SystemTap apenas se você não tiver outra solução, porque é uma estrutura totalmente nova que você precisa aprender e que custa tempo / dinheiro e, às vezes, frustração.

Fui em frente e escrevi um script stap para isso. Existe um no wiki systemtap, mas ele não parece estar correto. Nos testes básicos, isso parece bastante preciso, mas 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 é um bom começo, mas não fornece as informações que você procura (não se deixe enganar pelas porcentagens de acertos / perdidos em sistemas com vários núcleos e estatísticas ativadas; essas são outras coisas). Até onde eu sei, não há uma maneira de extrair essa informação específica do kernel, embora não deva ser terrivelmente difícil escrever um pouco de código para fazer.

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

Agora existe o utilitário cachestat do pacote perf-tools .

O autor também lista algumas alternativas (possivelmente mais cruéis) que as pessoas usam:

A) Estude a taxa de erros de cache da página usando o iostat (1) para monitorar leituras de disco e suponha que sejam erros de cache e não, por exemplo, O_DIRECT. A taxa de erros geralmente é uma métrica mais importante que a proporção, pois os erros são proporcionais à dor do aplicativo. Também use free (1) para ver os tamanhos do cache.

B) Solte o cache da página (eco 1> / proc / sys / vm / drop_caches) e meça quanto desempenho piora! Adoro o uso de um experimento negativo, mas é claro que essa é uma maneira dolorosa de esclarecer o uso do cache.

C) Use sar (1) e estude falhas menores e maiores. Eu não acho que isso funcione (por exemplo, E / S regular).

D) Use o script cache-hit-rate.stp SystemTap, que é o número dois em uma pesquisa na Internet pela taxa de acertos do cache de páginas do Linux. Ele instrumenta o acesso ao cache alto na pilha, na interface VFS, para que as leituras de qualquer sistema de arquivos ou dispositivo de armazenamento possam ser vistas. As falhas de cache são medidas através de suas E / S de disco. Isso também perde alguns tipos de carga de trabalho (alguns são mencionados em "Lições" nessa página) e chama proporções de "taxas".

Se você estiver interessado na proporção de erros / falhas de E / S de um processo específico, uma abordagem simples, mas muito eficaz, é ler o /proc/<pid>/ioarquivo.

Aqui você encontrará 4 valores-chave:

• rchar: o número total de bytes de leitura do ponto de vista do aplicativo (ou seja: sem diferença entre a leitura satisfeita do armazenamento físico e não do cache)
• wchar: como acima, mas sobre bytes escritos
• read_bytes: os bytes realmente leram do subsistema de armazenamento
• write_bytes: os bytes realmente gravados no subsistema de armazenamento

Digamos que um processo tenha os seguintes valores:

rchar: 1000000
read_bytes: 200000

A taxa de erros de cache de leitura (em bytes) é 100*200000/1000000 = 20%e a taxa de acertos é100-20 = 80%

No entanto, há um problema: o rcharvalor inclui tty IO, portanto, para processos que lêem / gravam muito de / para um canal, o cálculo acima será distorcido, relatando uma taxa de acerto mais alta que a efetiva.