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

Question

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

    

Answer 1

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 os probes "vfs.read", "vfs.write" e "kernel.function (" vfs_ * ")"; você precisa filtrar os dispositivos de bloco que deseja monitorar por seus respectivos números maiores + menores.
• Bloco: representa todas as solicitações de E / S enviadas aos dispositivos de bloco antes do planejador de E / S (que também mescla + reordenar as solicitações de E / S); aqui nós sabemos quais solicitações foram perdidas pelo cache Buffer; revise a análise "ioblock.request".

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

Note que o seu kernel deve ter suporte para carregar e descarregar módulos do kernel. A maioria dos núcleos de estoque hoje em dia suportam 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 fazer o download de um arquivo .deb de várias centenas de MB, que a equipe de desenvolvimento do kernel do Ubuntu compilou para mim. Isto é explicado na página Wiki SystemtapOnUbuntu , por exemplo.

P.S. Pegue a abordagem do SystemTap somente 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.

    

Answer 2

Eu fui em frente e escrevi um roteiro para isso. Há um na wiki systemtap, mas não parece estar correto. Em 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
}

    

Answer 3

/ proc / slabinfo é um bom começo, mas não fornece a informação que você está procurando (não se deixe enganar pelas percentagens de acertos / erros em sistemas com múltiplos núcleos e estatísticas ativadas; isso é algo outro). Até onde sei, não há uma maneira de extrair essas informações específicas do kernel, embora não seja muito difícil escrever um pouco de código para fazer.

Editar: link

    

Answer 4

Agora, há o utilitário cachestat de < um pacote do href="https://github.com/brendangregg/perf-tools"> perf-tools .

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

A) Study the page cache miss rate by using iostat(1) to monitor disk reads, and assume these are cache misses, and not, for example, O_DIRECT. The miss rate is usually a more important metric than the ratio anyway, since misses are proportional to application pain. Also use free(1) to see the cache sizes.

B) Drop the page cache (echo 1 > /proc/sys/vm/drop_caches), and measure how much performance gets worse! I love the use of a negative experiment, but this is of course a painful way to shed some light on cache usage.

C) Use sar(1) and study minor and major faults. I don't think this works (eg, regular I/O).

D) Use the cache-hit-rate.stp SystemTap script, which is number two in an Internet search for Linux page cache hit ratio. It instruments cache access high in the stack, in the VFS interface, so that reads to any file system or storage device can be seen. Cache misses are measured via their disk I/O. This also misses some workload types (some are mentioned in "Lessons" on that page), and calls ratios "rates".

    

Answer 5

Se você estiver interessado na taxa de hit / miss de um processo específico, uma abordagem simples, mas muito eficaz, é ler o arquivo /proc/<pid>/io .

Aqui você encontrará 4 valores-chave:

• rchar : o número total de bytes de leitura do ponto de vista do aplicativo (isto é: sem diferença entre a leitura satisfeita do armazenamento físico e não do cache)
• wchar : como acima, mas sobre bytes gravados
• read_bytes : os bytes realmente são lidos a partir 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 falta de leitura do cache (em bytes) é 100*200000/1000000 = 20% e a taxa de acertos é 100-20 = 80%

Há um problema, no entanto: o valor rchar inclui coisa como tty IO, portanto, para processos que lêem / escrevem muito de / para um pipe, o cálculo acima será distorcido, relatando uma taxa de acertos maior que a efetiva. .