- Quelle est la différence entre les "tampons" et l'autre type de cache ?
- Pourquoi cette distinction est-elle si importante ? Pourquoi certaines personnes parlent-elles de "cache tampon" lorsqu'elles parlent de contenu de fichier mis en cache ?
- Que sont
Buffersutilisé pour ? - Pourquoi pourrions-nous nous attendre à
Buffersen particulier pour être plus grand ou plus petit ?
1. Quelle est la différence entre les "tampons" et l'autre type de cache ?
Buffers affiche la quantité de cache de page utilisée pour les périphériques de bloc. Les "périphériques en mode bloc" sont le type de périphérique de stockage de données le plus courant.
Le noyau doit délibérément soustraire ce montant du reste du cache de la page lorsqu'il signale Cached . Voir 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. Pourquoi cette distinction est-elle si importante ? Pourquoi certaines personnes parlent-elles de "cache tampon" lorsqu'elles parlent de contenu de fichier mis en cache ?
Le cache de page fonctionne en unités de la taille de page MMU, généralement un minimum de 4096 octets. Ceci est essentiel pour mmap() , c'est-à-dire l'accès aux fichiers mappés en mémoire.[1][2] Il est conçu pour partager des pages de code de programme / bibliothèque chargé entre des processus distincts et permettre le chargement de pages individuelles à la demande. (Également pour décharger des pages lorsque quelque chose d'autre a besoin d'espace et qu'elles n'ont pas été utilisées récemment).
[1] E/S mappées en mémoire - Le manuel de la bibliothèque GNU C.
[2] mmap - Wikipédia.
Les premiers UNIX avaient un "cache tampon" de blocs de disque et n'avaient pas mmap(). Apparemment, lorsque mmap() a été ajouté pour la première fois, ils ont ajouté le cache de la page en tant que nouveau calque par-dessus. C'est aussi désordonné que cela puisse paraître. Finalement, les systèmes d'exploitation basés sur UNIX se sont débarrassés du cache de tampon séparé. Alors maintenant, tout le cache de fichiers est en unités de pages. Les pages sont recherchées par (fichier, décalage), et non par emplacement sur le disque. Cela s'appelait "cache tampon unifié", peut-être parce que les gens connaissaient mieux le "cache tampon".[3]
[3] UBC :un sous-système efficace d'E/S unifiées et de mise en cache de la mémoire pour NetBSD
("Une tournure intéressante que Linux ajoute est que les numéros de bloc de périphérique où une page est stockée sur le disque sont mis en cache avec la page sous la forme d'une liste de buffer_head structures. Lorsqu'une page modifiée doit être réécrite sur le disque, les requêtes d'E/S peuvent être envoyées immédiatement au pilote de périphérique, sans avoir besoin de lire des blocs indirects pour déterminer où les données de la page doivent être écrites."[3])
Dans Linux 2.2, il y avait un "cache tampon" séparé utilisé pour les écritures, mais pas pour les lectures. "Le cache de page a utilisé le cache de tampon pour réécrire ses données, nécessitant une copie supplémentaire des données et doublant les besoins en mémoire pour certaines charges d'écriture".[4] Ne nous inquiétons pas trop des détails, mais cet historique serait une des raisons pour lesquelles Linux rapporte Buffers utiliser séparément.
[4] Remplacement de page dans la gestion de la mémoire de Linux 2.4, Rik van Riel.
En revanche, sous Linux 2.4 et supérieur, la copie supplémentaire n'existe pas. "Le système effectue des E/S de disque directement vers et depuis la page de cache de page."[4] Linux 2.4 est sorti en 2001.
3. Que sont Buffers utilisé pour ?
Les périphériques de bloc sont traités comme des fichiers et ont donc un cache de page. Ceci est utilisé "pour les métadonnées du système de fichiers et la mise en cache des périphériques de bloc bruts".[4] Mais dans les versions actuelles de Linux, les systèmes de fichiers ne copient pas le contenu des fichiers, il n'y a donc pas de "double cache".
Je pense au Buffers une partie du cache de page comme étant le cache de tampon Linux. Certaines sources peuvent ne pas être d'accord avec cette terminologie.
La quantité de mémoire tampon utilisée par le système de fichiers, le cas échéant, dépend du type de système de fichiers. Le système dans la question utilise ext4. ext3/ext4 utilise le cache tampon Linux pour le journal, le contenu du répertoire et certaines autres métadonnées.
Certains systèmes de fichiers, notamment ext3, ext4 et ocfs2, utilisent la couche jbd ou jbd2 pour gérer leur journalisation physique des blocs, et cette couche utilise fondamentalement le cache de tampon.
-- Article par e-mail de Ted Tso, 2013
Avant la version 2.4 du noyau Linux, Linux avait des caches de pages et de tampons séparés. Depuis la 2.4, la page et le cache de tampon sont unifiés et
Bufferscorrespond aux blocs de disque bruts non représentés dans le cache de page, c'est-à-dire qu'il ne s'agit pas de données de fichier....
Le cache de tampon reste cependant, car le noyau doit toujours effectuer des E/S de bloc en termes de blocs, pas de pages. Comme la plupart des blocs représentent des données de fichier, la majeure partie du cache de tampon est représentée par le cache de page. Mais une petite quantité de données de bloc n'est pas sauvegardée sur fichier (les métadonnées et les E/S brutes de bloc par exemple) et est donc uniquement représentée par le cache de tampon.
-- Une paire de réponses Quora par Robert Love, dernière mise à jour 2013.
Les deux auteurs sont des développeurs Linux qui ont travaillé avec la gestion de la mémoire du noyau Linux. La première source est plus précise sur les détails techniques. La deuxième source est un résumé plus général, qui peut être contredit et obsolète dans certains détails.
Il est vrai que les systèmes de fichiers peuvent effectuer des écritures de métadonnées de pages partielles, même si le cache est indexé en pages. Même les processus utilisateur peuvent effectuer des écritures de pages partielles lorsqu'ils utilisent write() (par opposition à mmap() ), au moins directement à un périphérique bloc. Cela ne s'applique qu'aux écritures, pas aux lectures. Lorsque vous lisez le cache de pages, le cache de pages lit toujours des pages entières.
Linus aimait dire que le cache de tampon n'est pas nécessaire pour effectuer des écritures de la taille d'un bloc, et que les systèmes de fichiers peuvent effectuer des écritures de métadonnées de page partielle même avec un cache de page attaché à leurs propres fichiers au lieu du périphérique de bloc. Je suis sûr qu'il a raison de dire que ext2 fait cela. ext3/ext4 avec son système de journalisation ne le fait pas. Il est moins clair quels étaient les problèmes qui ont conduit à cette conception. Les gens contre qui il fulminait en avaient assez d'expliquer.
ext4_readdir() n'a pas été modifié pour satisfaire la diatribe de Linus. Je ne vois pas non plus son approche souhaitée utilisée dans readdir() d'autres systèmes de fichiers. Je pense que XFS utilise également le cache tampon pour les répertoires. bcachefs n'utilise pas du tout le cache de page pour readdir(); il utilise son propre cache pour btrees. Je ne suis pas sûr de btrfs.
4. Pourquoi pourrions-nous nous attendre à Buffers en particulier pour être plus grand ou plus petit ?
Dans ce cas, il s'avère que la taille du journal ext4 pour mon système de fichiers est de 128 Mo. Cela explique donc pourquoi 1) mon cache tampon peut se stabiliser à un peu plus de 128 Mo ; 2) le cache de tampon ne s'adapte pas proportionnellement à la plus grande quantité de RAM sur mon ordinateur portable.
Pour d'autres causes possibles, consultez Qu'est-ce que la colonne des tampons dans la sortie de free ? Notez que les "tampons" signalés par free est en fait une combinaison de Buffers et mémoire de dalle de noyau récupérable.
Pour vérifier que les écritures de journal utilisent le cache de tampon, j'ai simulé un système de fichiers dans une RAM rapide et agréable (tmpfs) et j'ai comparé l'utilisation maximale du tampon pour différentes tailles de journal.
# 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
Historique de cette réponse :comment j'en suis venu à consulter le journal
J'avais d'abord trouvé l'e-mail de Ted Tso et j'étais intrigué qu'il mette l'accent sur écrire mise en cache. Je trouverais ça surprenant si "sale", non écrit les données ont pu atteindre 30% de RAM sur mon système. sudo atop montre que sur un intervalle de 10 secondes, le système en question n'écrit systématiquement que 1 Mo. Le système de fichiers concerné serait capable de suivre plus de 100 fois ce taux. (C'est sur un disque dur USB2, débit max ~20 Mo/s).
Utilisation de blktrace (btrace -w 10 /dev/sda ) confirme que les E/S mises en cache doivent être écrites, car il n'y a presque pas de données en cours de lecture. Aussi que mysqld est le seul espace utilisateur processus faisant IO.
J'ai arrêté le service responsable des écritures (icinga2 écrivant sur mysql) et revérifié. J'ai vu des "tampons" chuter à moins de 20M - je n'ai aucune explication à cela - et y rester. Redémarrer à nouveau l'enregistreur montre que les "tampons" augmentent d'environ 0,1 M pour chaque intervalle de 10 secondes. Je l'ai observé maintenir ce taux de manière constante, remontant à 70 M et plus.
Exécution de echo 3 | sudo tee /proc/sys/vm/drop_caches était suffisant pour abaisser à nouveau les "tampons", à 4,5 M. Cela prouve que mon accumulation de tampons est un cache "propre", que Linux peut supprimer immédiatement en cas de besoin. Ce système n'accumule pas non écrit Les données. (drop_caches n'effectue aucune écriture différée et ne peut donc pas supprimer les pages modifiées. Si vous vouliez exécuter un test qui nettoyait d'abord le cache, vous utiliseriez le sync commande).
L'intégralité du répertoire mysql ne fait que 150 Mo. Les tampons accumulés doivent représenter les blocs de métadonnées des écritures mysql, mais cela m'a surpris de penser qu'il y aurait autant de blocs de métadonnées pour ces données.
Votre version de free a la bonne idée. Par défaut, il combine les tampons et le cache dans son rapport. C'est parce qu'ils sont fondamentalement la même chose. Ce sont tous les deux l'ordinateur qui se souvient dans la RAM (plus rapide que le stockage secondaire :disques et SSD), de ce qu'il a déjà vu lors de la lecture du disque et du SSD.
Si le système d'exploitation estime que la mémoire est mieux utilisée par autre chose, il peut la libérer. Par conséquent, ne vous inquiétez pas du tampon et du cache.
Cependant, le fait de regarder un DVD peut entraîner l'augmentation du tampon et la suppression d'autres contenus du tampon/cache. Par conséquent, vous pouvez utiliser nocache pour exécuter le lecteur de DVD (si cela pose un problème ).