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

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           501M        146M         19M        9.7M        335M        331M
Swap:          1.0G         85M        938M

$ free -w -h
              total        used        free      shared     buffers       cache   available
Mem:           501M        146M         19M        9.7M        155M        180M        331M
Swap:          1.0G         85M        938M

Como posso descrever ou explicar "buffers" na saída de free?

Não tenho nenhum problema (conhecido) com este sistema. Estou apenas surpreso e curioso ao ver que "buffers" é quase tão alto quanto "cache" (155 milhões vs 180 milhões). Eu pensei que "cache" representasse o cache da página do conteúdo do arquivo e tende a ser a parte mais significativa de "cache / buffers". Sou menos claro para que servem os "buffers".

Por exemplo, comparei isso ao meu laptop, que possui mais memória RAM. No meu laptop, o número de "buffers" é uma ordem de magnitude menor que o "cache" (200 milhões vs 4G). Se eu tivesse um entendimento adequado do que eram "buffers", poderia começar a perguntar por que os buffers poderiam aumentar para uma proporção tão maior no sistema menor.

man proc (Ignoro a definição hilariamente desatualizada de "grande"):

Buffers% lu

Armazenamento relativamente temporário para blocos de disco bruto que não devem ser muito grandes (aproximadamente 20 MB).

% Lu armazenado em cache

Cache na memória para arquivos lidos no disco (o cache da página). Não inclui SwapCached.

$ free -V
free from procps-ng 3.3.12
$ uname -r
4.9.0-6-marvell
$ systemd-detect-virt
none

$ cat /proc/meminfo
MemTotal:         513976 kB
MemFree:           20100 kB
MemAvailable:     339304 kB
Buffers:          159220 kB
Cached:           155536 kB
SwapCached:         2420 kB
Active:           215044 kB
Inactive:         216760 kB
Active(anon):      56556 kB
Inactive(anon):    73280 kB
Active(file):     158488 kB
Inactive(file):   143480 kB
Unevictable:       10760 kB
Mlocked:           10760 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         513976 kB
LowFree:           20100 kB
SwapTotal:       1048572 kB
SwapFree:         960532 kB
Dirty:               240 kB
Writeback:             0 kB
AnonPages:        126912 kB
Mapped:            40312 kB
Shmem:              9916 kB
Slab:              37580 kB
SReclaimable:      29036 kB
SUnreclaim:         8544 kB
KernelStack:        1472 kB
PageTables:         3108 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1305560 kB
Committed_AS:    1155244 kB
VmallocTotal:     507904 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB

$ sudo slabtop --once
 Active / Total Objects (% used)    : 186139 / 212611 (87.5%)
 Active / Total Slabs (% used)      : 9115 / 9115 (100.0%)
 Active / Total Caches (% used)     : 66 / 92 (71.7%)
 Active / Total Size (% used)       : 31838.34K / 35031.49K (90.9%)
 Minimum / Average / Maximum Object : 0.02K / 0.16K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 59968  57222   0%    0.06K    937       64      3748K buffer_head            
 29010  21923   0%    0.13K    967       30      3868K dentry                 
 24306  23842   0%    0.58K   4051        6     16204K ext4_inode_cache       
 22072  20576   0%    0.03K    178      124       712K kmalloc-32             
 10290   9756   0%    0.09K    245       42       980K kmalloc-96             
  9152   4582   0%    0.06K    143       64       572K kmalloc-node           
  9027   8914   0%    0.08K    177       51       708K kernfs_node_cache      
  7007   3830   0%    0.30K    539       13      2156K radix_tree_node        
  5952   4466   0%    0.03K     48      124       192K jbd2_revoke_record_s   
  5889   5870   0%    0.30K    453       13      1812K inode_cache            
  5705   4479   0%    0.02K     35      163       140K file_lock_ctx          
  3844   3464   0%    0.03K     31      124       124K anon_vma               
  3280   3032   0%    0.25K    205       16       820K kmalloc-256            
  2730   2720   0%    0.10K     70       39       280K btrfs_trans_handle     
  2025   1749   0%    0.16K     81       25       324K filp                   
  1952   1844   0%    0.12K     61       32       244K kmalloc-128            
  1826    532   0%    0.05K     22       83        88K trace_event_file       
  1392   1384   0%    0.33K    116       12       464K proc_inode_cache       
  1067   1050   0%    0.34K     97       11       388K shmem_inode_cache      
   987    768   0%    0.19K     47       21       188K kmalloc-192            
   848    757   0%    0.50K    106        8       424K kmalloc-512            
   450    448   0%    0.38K     45       10       180K ubifs_inode_slab       
   297    200   0%    0.04K      3       99        12K eventpoll_pwq          
   288    288 100%    1.00K     72        4       288K kmalloc-1024           
   288    288 100%    0.22K     16       18        64K mnt_cache              
   287    283   0%    1.05K     41        7       328K idr_layer_cache        
   240      8   0%    0.02K      1      240         4K fscrypt_info           

1. Qual é a diferença entre "buffer" e o outro cache?
2. Por que vemos essa distinção tão proeminentemente? (Possível motivo histórico)
3. Para que são Buffersutilizados?
4. Por que podemos esperar, Buffersem particular, ser maior ou menor?

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

Buffersrelata a quantidade de cache da página usada para dispositivos de bloco. O kernel precisa subtrair deliberadamente esse valor do restante do cache da página quando ele relatar 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 vemos essa distinção tão proeminentemente? (Possível motivo histórico)

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

[1] E / S mapeada na memória - O manual da GNU C Library.
[2] mmap- Wikipedia.

O UNIX anterior tinha um "cache de buffer" de blocos de disco e não possuía mmap (). Aparentemente, quando o mmap () foi adicionado pela primeira vez, eles simplesmente colocaram o cache da página em cima do cache do buffer. Isso é tão confuso quanto parece. Eventualmente, os sistemas operacionais baseados em UNIX se livraram do cache do buffer. Então agora todo o cache de arquivos está em unidades de páginas. As páginas são pesquisadas por (arquivo, deslocamento), não pelo local no disco. Isso foi chamado de "cache de buffer unificado", talvez porque as pessoas estivessem mais familiarizadas com o "cache de buffer". [3]

[3] UBC: um subsistema de E / S unificada eficiente e cache de memória para o NetBSD

"Uma reviravolta interessante que o Linux acrescenta é que os números de bloco do dispositivo em que 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, a E / S as solicitações podem ser enviadas ao 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 da página usou o cache do buffer para gravar seus dados, precisando de uma cópia extra dos dados e duplicando 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 um dos motivos pelos quais o Linux relata o Buffersuso 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 o IO do 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 são Buffersutilizados?

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

Penso na Buffersparte do cache da página como sendo o cache do buffer do Linux. Embora algumas fontes possam discordar dessa terminologia.

A quantidade de cache de buffer que o sistema de arquivos usa, se houver, depende dos detalhes do sistema de arquivos específico. O sistema na pergunta usa ext4. ext3 / ext4 usa o cache do 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 o diário de bloco físico, e essa camada usa fundamentalmente o cache do buffer.

- Artigo de e - mail de Ted Tso , 2013

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

...

O cache do buffer permanece, no entanto, como 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 do arquivo, a maior parte do cache do buffer é representada pelo cache da página. Mas uma pequena quantidade de dados de bloco não é suportada por arquivos - metadados e E / S de bloco bruto, por exemplo - e, portanto, é representada apenas pelo cache do buffer.

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

Ambos os escritores são desenvolvedores de Linux que trabalharam com o gerenciamento de memória do kernel do 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 esteja indexado em páginas. Até 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 leituras. Quando você lê o cache da página, ele sempre lê páginas inteiras.

Linus gostava de reclamar que o cache do buffer não é necessário para realizar gravações em tamanho de bloco e que os sistemas de arquivos podem gravar metadados de páginas parciais, mesmo com o cache de páginas anexado aos seus próprios arquivos, em vez do dispositivo de bloco. Estou certo de que ele está certo ao dizer que o ext2 faz isso. ext3 / ext4 com seu sistema de diário não. É menos claro quais foram os problemas que levaram a esse design. As pessoas que 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. Eu acho que o XFS também usa o cache do buffer para diretórios. O bcachefs não usa o cache da página para readdir (); ele usa seu próprio cache para btrees. Eu posso estar perdendo algo no btrfs.

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

Nesse caso, o tamanho do diário ext4 para o meu sistema de arquivos é de 128M. Portanto, isso explica por que 1) meu cache de buffer pode se estabilizar um pouco acima de 128M; 2) o cache do buffer não aumenta proporcionalmente à maior quantidade de RAM do meu laptop.

Para outras causas possíveis, consulte Qual é a coluna de buffers na saída do free? Observe que os "buffers" relatados por freena verdade são uma combinação Bufferse uma memória de laje recuperável.

Para verificar se as gravações do diário usam o cache do buffer, simulei um sistema de arquivos na 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órico desta resposta: Como vim para a revista

Eu havia encontrado o e-mail de Ted Tso primeiro e fiquei intrigado ao enfatizar o cache de gravação . Eu consideraria surpreendente se os dados não escritos "sujos" fossem capazes de 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 de ~ 20 MB / s).

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

Parei o serviço responsável pelas gravações (icinga2 escrevendo no mysql) e verifiquei novamente. Vi "buffers" cair para menos de 20 milhões - não tenho explicação para isso - e fico lá. Reiniciar o gravador novamente mostra "buffers" aumentando em ~ 0,1M a cada intervalo de 10 segundos. Eu observei que ele mantinha essa taxa de forma consistente, voltando aos 70 milhões e acima.

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

O diretório mysql inteiro é de apenas 150M. Os buffers acumulativos 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 do 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 os computadores que estão 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 achar que a memória é melhor usada por outra coisa, poderá 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 despeje outro conteúdo de buffer / cache. Portanto, você pode usar o nocache para executar o DVD player ( se estiver causando um problema ).