30% da RAM são "buffers". O que é isso?

1. Qual é a diferença entre "buffers" e o outro tipo de cache?
2. Por que essa distinção é tão proeminente? Por que algumas pessoas dizem "cache de buffer" quando falam sobre o conteúdo do arquivo em cache?
3. Para que Buffersservem?
4. Por que podemos esperar, Buffersem particular, que seja maior ou menor?

1. Qual é a diferença entre "buffers" e outro tipo de cache?

Buffersmostra a quantidade de cache de página usada para dispositivos de bloco. "Dispositivos de bloco" são o tipo mais comum de dispositivo de armazenamento de dados.

O kernel tem que subtrair deliberadamente esta quantidade do resto do cache da página quando ele relata Cached. Veja meminfo_proc_show() :

cached = global_node_page_state(NR_FILE_PAGES) -
         total_swapcache_pages() - i.bufferram;
...

show_val_kb(m, "MemTotal:       ", i.totalram);
show_val_kb(m, "MemFree:        ", i.freeram);
show_val_kb(m, "MemAvailable:   ", available);
show_val_kb(m, "Buffers:        ", i.bufferram);
show_val_kb(m, "Cached:         ", cached);

2. Por que essa distinção é tão proeminente? Por que algumas pessoas dizem "cache de buffer" quando falam sobre o conteúdo do arquivo em cache?

O cache de página funciona em unidades do tamanho da página MMU, normalmente um mínimo de 4096 bytes. Isso é essencial para mmap(), ou seja, acesso a arquivos mapeados na memória.[1][2] Ele foi projetado para compartilhar páginas de programa carregado/código de biblioteca entre processos separados e permitir o carregamento de páginas individuais sob demanda. (Também para descarregar páginas quando algo mais precisa de espaço e não foi usado recentemente).

[1] E/S mapeada em memória - O manual da biblioteca GNU C.
[2] mmap- Wikipédia.

O UNIX antigo tinha um "cache de buffer" de blocos de disco e não tinha mmap(). Aparentemente, quando mmap() foi adicionado pela primeira vez, eles adicionaram o cache da página como uma nova camada no topo. Isso é tão confuso quanto parece. Eventualmente, o sistema operacional baseado em UNIX se livrou do cache de buffer separado. Portanto, agora todo o cache de arquivos está em unidades de páginas. As páginas são procuradas por (arquivo, deslocamento), não por localização no disco. Isso foi chamado de "cache de buffer unificado", talvez porque as pessoas estivessem mais familiarizadas com "cache de buffer".[3]

[3] UBC: Um E/S Unificado Eficiente e Subsistema de Cache de Memória para NetBSD

("Uma reviravolta interessante que o Linux adiciona é que os números do bloco de dispositivo onde uma página é armazenada no disco são armazenados em cache com a página na forma de uma lista de buffer_headestruturas. Quando uma página modificada deve ser gravada de volta no disco, o I/ As solicitações podem ser enviadas para o driver do dispositivo imediatamente, sem a necessidade de ler nenhum bloco indireto para determinar onde os dados da página devem ser gravados."[3])

No Linux 2.2, havia um "cache de buffer" separado usado para gravações, mas não para leituras. "O cache de página usou o cache de buffer para gravar novamente seus dados, precisando de uma cópia extra dos dados e dobrando os requisitos de memória para algumas cargas de gravação".[4] Não vamos nos preocupar muito com os detalhes, mas esse histórico seria uma das razões pelas quais o Linux relata Bufferso uso separadamente.

[4] Substituição de página no gerenciamento de memória do Linux 2.4 , Rik van Riel.

Por outro lado, no Linux 2.4 e superior, a cópia extra não existe. "O sistema faz I/O de disco diretamente de e para a página de cache da página."[4] O Linux 2.4 foi lançado em 2001.

3. Para que Buffersservem?

Os dispositivos de bloco são tratados como arquivos e, portanto, possuem cache de página. Isso é usado "para metadados do sistema de arquivos e cache de dispositivos de blocos brutos".[4] Mas nas versões atuais do Linux, os sistemas de arquivos não copiam o conteúdo do arquivo por meio dele, portanto, não há "cache duplo".

Penso na Buffersparte do cache da página como sendo o cache do buffer do Linux. Algumas fontes podem discordar dessa terminologia.

Quanto cache de buffer o sistema de arquivos usa, se houver, depende do tipo de sistema de arquivos. O sistema na pergunta usa ext4. ext3/ext4 usam o cache de buffer do Linux para o diário, para o conteúdo do diretório e alguns outros metadados.

Certos sistemas de arquivos, incluindo ext3, ext4 e ocfs2, usam a camada jbd ou jbd2 para lidar com seu diário de bloco físico, e essa camada usa fundamentalmente o cache do buffer.

-- Artigo por e - mail de Ted Tso , 2013

Antes da versão 2.4 do kernel do Linux, o Linux tinha caches de página e buffer separados. Desde 2.4, a página e o cache do buffer são unificados e Bufferssão blocos de disco brutos não representados no cache da página - ou seja, não são dados de arquivo.

...

O cache do buffer permanece, no entanto, pois o kernel ainda precisa executar E/S de bloco em termos de blocos, não de páginas. Como a maioria dos blocos representa dados de arquivo, a maior parte do cache do buffer é representada pelo cache da página. Mas uma pequena quantidade de dados de bloco não é protegida por arquivo - metadados e E/S de bloco bruto, por exemplo - e, portanto, é representada apenas pelo cache do buffer.

-- Um par de respostas do Quora por Robert Love , atualizado pela última vez em 2013.

Ambos os escritores são desenvolvedores Linux que trabalharam com gerenciamento de memória do kernel Linux. A primeira fonte é mais específica sobre detalhes técnicos. A segunda fonte é um resumo mais geral, que pode ser contradito e desatualizado em alguns detalhes.

É verdade que os sistemas de arquivos podem executar gravações de metadados de página parcial, mesmo que o cache seja indexado em páginas. Mesmo os processos do usuário podem executar gravações de página parcial quando usam write()(ao contrário de mmap()), pelo menos diretamente em um dispositivo de bloco. Isso se aplica apenas a gravações, não a leituras. Quando você lê o cache da página, o cache da página sempre lê páginas inteiras.

Linus gostava de reclamar que o cache do buffer não é necessário para fazer gravações do tamanho de bloco e que os sistemas de arquivos podem fazer gravações de metadados de página parcial mesmo com o cache de página anexado a seus próprios arquivos em vez do dispositivo de bloco. Tenho certeza de que ele está certo ao dizer que o ext2 faz isso. ext3/ext4 com seu sistema de journalling não. É menos claro quais foram os problemas que levaram a esse projeto. As pessoas com quem ele estava reclamando se cansaram de explicar.

ext4_readdir() não foi alterado para satisfazer o discurso de Linus. Também não vejo a abordagem desejada usada em readdir () de outros sistemas de arquivos. Acho que o XFS também usa o cache de buffer para diretórios. bcachefs não usa o cache da página para readdir(); ele usa seu próprio cache para btrees. Não tenho certeza sobre btrfs.

4. Por que podemos esperar, Buffersem particular, que seja maior ou menor?

Nesse caso, o tamanho do diário ext4 para meu sistema de arquivos é 128M. Isso explica por que 1) meu cache de buffer pode se estabilizar em pouco mais de 128M; 2) o cache do buffer não é dimensionado proporcionalmente com a maior quantidade de RAM no meu laptop.

Para algumas outras causas possíveis, consulte Qual é a coluna de buffers na saída de free? Observe que "buffers" relatados por freesão, na verdade, uma combinação de Buffersmemória slab do kernel recuperável.

Para verificar se as gravações do diário usam o cache do buffer, simulei um sistema de arquivos em RAM rápida e agradável (tmpfs) e comparei o uso máximo do buffer para diferentes tamanhos de diário.

# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=256
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size:             256M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2521        4321         285          66         947        5105
Swap:          7995           0        7995

# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2523        3872         551         237        1223        4835
Swap:          7995           0        7995

# dd if=/dev/zero of=/tmp/t bs=1M count=1000
...
# mkfs.ext4 /tmp/t -J size=16
...
# LANG=C dumpe2fs /tmp/t | grep '^Journal size'
dumpe2fs 1.43.5 (04-Aug-2017)
Journal size:             16M
# mount /tmp/t /mnt
# cd /mnt
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2507        4337         285          66         943        5118
Swap:          7995           0        7995

# for i in $(seq 40000); do dd if=/dev/zero of=t bs=1k count=1 conv=sync status=none; sync t; sync -f t; done
# free -w -m
              total        used        free      shared     buffers       cache   available
Mem:           7855        2509        4290         315          77         977        5086
Swap:          7995           0        7995

História desta resposta: Como vim a olhar para o diário

Encontrei o e-mail de Ted Tso primeiro e fiquei intrigado com o fato de ele enfatizar o cache de gravação . Eu acharia surpreendente se dados "sujos" não gravados pudessem atingir 30% da RAM no meu sistema. sudo atopmostra que, em um intervalo de 10 segundos, o sistema em questão grava consistentemente apenas 1 MB. O sistema de arquivos em questão seria capaz de acompanhar mais de 100 vezes essa taxa. (Está em uma unidade de disco rígido USB2, taxa de transferência máxima ~ 20 MB/s).

O uso de blktrace ( btrace -w 10 /dev/sda) confirma que os IOs que estão sendo armazenados em cache devem ser gravados, porque quase não há dados sendo lidos. Além disso, esse mysqldé o único processo de espaço de usuário fazendo IO.

Parei o serviço responsável pelas gravações (icinga2 gravando no mysql) e verifiquei novamente. Eu vi "buffers" cair para menos de 20M - não tenho explicação para isso - e ficar lá. Reiniciar o gravador novamente mostra "buffers" aumentando em ~ 0,1M para cada intervalo de 10 segundos. Observei que ele mantém essa taxa de forma consistente, subindo de volta para 70M e acima.

A execução echo 3 | sudo tee /proc/sys/vm/drop_cachesfoi suficiente para reduzir os "buffers" novamente, para 4,5M. Isso prova que meu acúmulo de buffers é um cache "limpo", que o Linux pode descartar imediatamente quando necessário. Este sistema não está acumulando dados não gravados . ( drop_cachesnão executa nenhum write-back e, portanto, não pode descartar páginas sujas. Se você quiser executar um teste que limpe o cache primeiro, use o synccomando).

Todo o diretório mysql tem apenas 150M. Os buffers acumulados devem representar blocos de metadados das gravações do mysql, mas me surpreendeu pensar que haveria tantos blocos de metadados para esses dados.

Sua versão de freetem a ideia certa. Por padrão, ele combina buffers e cache em seu relatório. Isso ocorre porque eles são basicamente a mesma coisa. Ambos são o computador lembrando na RAM (Mais rápido que o armazenamento secundário: Discos e SSD), o que ele já viu ao ler Disco e SSD.

Se o sistema operacional sentir que a memória é melhor usada por outra coisa, ele pode liberá-la. Portanto, não se preocupe com buffer e cache.

No entanto, assistir a um DVD pode fazer com que o buffer suba e elimine outro conteúdo de buffer/cache. Portanto, você pode usar o nocache para executar o reprodutor de DVD ( se estiver causando um problema ).