Até Linux, a Page Cache acelera muitos acessos a ficheiros em armazenamento não volátil. Isto acontece porque, quando lê ou escreve pela primeira vez em suportes de dados como discos rígidos, o Linux também armazena dados em áreas de memória não utilizadas, que funcionam como cache. Se esses dados forem lidos novamente mais tarde, eles podem ser lidos rapidamente a partir desse cache na memória. Este artigo irá fornecer informações de fundo valiosas sobre o cache desta página.
Cache de Página ou Cache de Buffer
O termo, Cache de Buffer, é frequentemente usado para o Cache de Página. Os kernels Linux até a versão 2.2 tinham tanto um Page Cache como um Buffer Cache. A partir do kernel 2.4, estes dois caches foram combinados. Hoje, existe apenas uma cache, a Page Cache.
Functional Approach
Memory Usage
Usobre Linux, o número de megabytes de memória principal actualmente utilizado para a cache de páginas é indicado na coluna Cache do relatório produzido pelo comando free -m.
# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999#
Escrita
Se os dados são escritos, são primeiro escritos no Cache de Páginas e geridos como uma das suas páginas sujas. Dirty significa que os dados são armazenados no Page Cache, mas precisam ser escritos primeiro no dispositivo de armazenamento subjacente. O conteúdo dessas páginas sujas é periodicamente transferido (assim como com a sincronização de chamadas do sistema ou fsync) para o dispositivo de armazenamento subjacente. O sistema pode, nesta última instância, ser um controlador RAID ou o disco rígido directamente.
O exemplo seguinte mostrará a criação de um ficheiro de 10 megabytes, que será primeiro escrito no Cache de Páginas. O número de páginas sujas será aumentado ao fazê-lo, até que elas tenham sido escritas na unidade de estado sólido (SSD) subjacente, neste caso manualmente em resposta ao comando sync.
wfischer@pc:~$ dd if=/dev/zero of=testfile.txt bs=1M count=1010+0 records in10+0 records out10485760 bytes (10 MB) copied, 0,0121043 s, 866 MB/swfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 10260 kBwfischer@pc:~$ syncwfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 0 kB
Up para a Versão 2.6.31 do Kernel: pdflush
Up para e incluindo a 2.6.31 versão do kernel Linux, os threads pdflush asseguraram que páginas sujas fossem periodicamente escritas no dispositivo de armazenamento subjacente.
As da Versão 2.6.32: por-backing-device based writeback
Desde que o pdflush tinha várias desvantagens de desempenho, Jens Axboe desenvolveu um novo mecanismo de writeback mais eficaz para a versão 2.6.32 do Kernel Linux.
Esta abordagem fornece threads para cada dispositivo, como o seguinte exemplo de um computador com um SSD (/dev/sda) e um disco rígido (/dev/sdb) mostra.
root@pc:~# ls -l /dev/sdabrw-rw---- 1 root disk 8, 0 2011-09-01 10:36 /dev/sdaroot@pc:~# ls -l /dev/sdbbrw-rw---- 1 root disk 8, 16 2011-09-01 10:36 /dev/sdbroot@pc:~# ps -eaf | grep -i flushroot 935 2 0 10:36 ? 00:00:00 root 936 2 0 10:36 ? 00:00:00
Leitura
Blocos de arquivo são escritos no Page Cache não apenas durante a escrita, mas também ao ler arquivos. Por exemplo, quando você lê um arquivo de 100 megabytes duas vezes, uma após a outra, o segundo acesso será mais rápido, pois os blocos de arquivo vêm diretamente do Page Cache na memória e não precisam ser lidos do disco rígido novamente. O exemplo seguinte mostra que o tamanho do Page Cache aumentou depois de um bom vídeo de 200 megabytes ter sido reproduzido.
user@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 1812 2071 0 60 1328-/+ buffers/cache: 424 3459Swap: 1956 0 1956user@adminpc:~$ vlc video.aviuser@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 2056 1827 0 60 1566-/+ buffers/cache: 429 3454Swap: 1956 0 1956user@adminpc:~$
Se o Linux necessitar de mais memória para aplicações normais do que está actualmente disponível, áreas do Page Cache que já não estão a ser utilizadas serão automaticamente apagadas.
Optimizar o Page Cache
O armazenamento automático dos blocos de ficheiro no Page Cache é geralmente bastante vantajoso. Alguns dados, tais como arquivos de log ou arquivos dump do MySQL, não são mais necessários uma vez que tenham sido escritos. Portanto, tais blocos de arquivos frequentemente usam espaço no Page Cache desnecessariamente. Outros blocos de ficheiros, cujo armazenamento seria mais vantajoso, podem ser prematuramente apagados do Cache de Página por novos ficheiros log ou MySQL.
Execução periódica do logrotate com compressão gzip pode ajudar com os ficheiros log, de alguma forma. Quando um arquivo de 500 megabytes de log é comprimido em 10 megabytes por logrotate e gzip, o arquivo de log original torna-se inválido junto com o seu espaço de cache. 490 megabytes na página Cache ficará então disponível ao fazer isso. O perigo de um ficheiro de log em contínuo crescimento deslocar blocos de ficheiros mais úteis do Page Cache é assim reduzido.
Por isso, é completamente razoável, se algumas aplicações normalmente não armazenariam certos ficheiros e blocos de ficheiros na cache. Já existe tal correcção disponível para rsync.
- The Buffer Cache (Secção 15.3) página 348, Manual do Linux-Kernel: Guidelines for the Design and Implementation of Kernel 2.6, Robert Love, Addison-Wesley, 2005
- Linux 2.6. – 32 Per-backing-device based writeback (kernelnewbies.org)
- Clearing The Linux Buffer Cache (blog.straylightrun.net, 03.12.2009)
- Melhorando a performance do Linux preservando o estado de cache de buffer (insights.oetiker.ch)
Informação adicional
- Page Cache, the Affair Between Memory and Files (Blog)
- Estado de cache de buffer do Linux (Blog)
- The Linux Page Cache and pdflush: Theory of Operation and Tuning for Write-Heavy Loads (Last update 8/08/2007)
- drop_caches (linuxinsight.com)
- Examining Linux 2.6 Page-Cache Performance (linuxinsight.com)
- Page cache (en.wikipedia.org)