Bazele cache-ului de pagină Linux

În Linux, cache-ul de pagină accelerează multe accesări ale fișierelor de pe memoria nevolatilă. Acest lucru se întâmplă deoarece, atunci când citește pentru prima dată de pe sau scrie pe suporturi de date, cum ar fi hard disk-urile, Linux stochează, de asemenea, date în zone neutilizate ale memoriei, care acționează ca o memorie cache. Dacă aceste date sunt citite din nou mai târziu, ele pot fi citite rapid din această memorie cache din memorie. Acest articol va furniza informații de bază valoroase despre acest cache de pagină.

Page Cache sau Buffer Cache

Termenul, Buffer Cache, este adesea folosit pentru Page Cache. Kernel-urile Linux până la versiunea 2.2 aveau atât un Page Cache, cât și un Buffer Cache. Începând cu kernelul 2.4, aceste două cache-uri au fost combinate. În prezent, există o singură memorie cache, Page Cache.

Abordare funcțională

Utilizarea memoriei

În Linux, numărul de megaocteți de memorie principală utilizați în prezent pentru cache-ul de pagină este indicat în coloana Cached din raportul produs de comanda free -m.

# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999# 

Scrierea

Dacă se scriu date, acestea sunt mai întâi scrise în Page Cache și gestionate ca una dintre paginile sale murdare. Dirty înseamnă că datele sunt stocate în Page Cache, dar trebuie să fie scrise mai întâi pe dispozitivul de stocare subiacent. Conținutul acestor pagini murdare este transferat periodic (precum și cu ajutorul apelurilor de sistem sync sau fsync) către dispozitivul de stocare subiacent. Sistemul poate fi, în acest ultim caz, un controler RAID sau direct hard disk-ul.

Exemplul următor va arăta crearea unui fișier de 10 megabyte, care va fi scris mai întâi în Page Cache. Numărul de pagini murdare va crește în acest fel, până când acestea vor fi scrise pe unitatea solid-state drive (SSD) subiacentă, în acest caz manual, ca răspuns la comanda de sincronizare.

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

Până la versiunea 2.6.31 a Kernel-ului: pdflush

Până la versiunea 2.6.31 inclusiv.31 a nucleului Linux, firele pdflush asigurau că paginile murdare erau scrise periodic pe dispozitivul de stocare subiacent.

De la versiunea 2.6.32: writeback bazat pe dispozitiv de backing

Din moment ce pdflush avea mai multe dezavantaje de performanță, Jens Axboe a dezvoltat un nou mecanism de writeback, mai eficient, pentru versiunea 2.6.32 a nucleului Linux.

Această abordare oferă fire de execuție pentru fiecare dispozitiv, așa cum arată exemplul următor al unui calculator cu un SSD (/dev/sda) și un hard disk (/dev/sdb).

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 

Lectura

Blocurile de fișiere sunt scrise în Page Cache nu doar în timpul scrierii, ci și la citirea fișierelor. De exemplu, atunci când citiți un fișier de 100 de megabyte de două ori, una după alta, a doua accesare va fi mai rapidă, deoarece blocurile de fișiere provin direct din Page Cache din memorie și nu trebuie să fie citite din nou de pe hard disk. Exemplul următor arată că dimensiunea Page Cache a crescut după ce a fost redat un videoclip bun, de 200 de megabytes.

Dacă Linux are nevoie de mai multă memorie pentru aplicațiile normale decât cea disponibilă în prezent, zonele din Page Cache care nu mai sunt utilizate vor fi șterse automat.

Optimizarea Page Cache

Stocarea automată a blocurilor de fișiere în Page Cache este, în general, destul de avantajoasă. Unele date, cum ar fi fișierele jurnal sau fișierele de vidare MySQL, nu mai sunt adesea necesare după ce au fost scrise. Prin urmare, astfel de blocuri de fișiere utilizează adesea spațiu în Page Cache în mod inutil. Alte blocuri de fișiere, a căror stocare ar fi mai avantajoasă, ar putea fi șterse prematur din Page Cache de către fișiere de jurnal mai noi sau de către MySQL.

Executarea periodică a programului logrotate cu compresie gzip poate ajuta cu fișierele de jurnal, într-o oarecare măsură. Atunci când un fișier jurnal de 500 de megabyte este comprimat în 10 megabyte de către logrotate și gzip, fișierul jurnal original devine invalid împreună cu spațiul său cache. 490 de megaocteți din Page Cache vor deveni apoi disponibili prin această operațiune. Se reduce astfel pericolul ca un fișier jurnal în continuă creștere să deplaseze blocuri de fișiere mai utile din Page Cache.

Prin urmare, este complet rezonabil, dacă unele aplicații nu ar stoca în mod normal anumite fișiere și blocuri de fișiere în memoria cache. Există deja un astfel de patch disponibil pentru rsync.

Informații suplimentare

• Page Cache, the Affair Between Memory and Files (Blog)
• Linux buffer cache state (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)