Question :Que sont les pages sales et à quoi servent-elles ?
Chaque fois que le processus d'application/base de données doit ajouter une page virtuelle dans la mémoire physique mais qu'il ne reste plus de pages physiques libres, le système d'exploitation doit effacer les anciennes pages restantes.
Maintenant, si l'ancienne page n'a pas été écrite du tout, celle-ci n'a pas besoin d'être enregistrée, elle peut être simplement récupérée à partir du fichier de données. Mais si l'ancienne page a déjà été modifiée, elle doit être conservée quelque part afin que l'application/la base de données puisse être réutilisée plus tard - c'est ce qu'on appelle une page sale.
Le système d'exploitation stocke ces pages sales dans des fichiers d'échange (afin qu'elles puissent être supprimées de la mémoire physique afin qu'une autre "nouvelle" page puisse être stockée dans la mémoire physique) goulot d'étranglement si le périphérique d'échange réel est situé sur le disque local ( sda ) et de plus, cela cause d'autres problèmes si le disque local est également utilisé par le disque racine local ( OS ).
Le cache de page sous Linux n'est qu'un cache disque qui apporte des performances supplémentaires au système d'exploitation, ce qui facilite les lectures/écritures intensives sur les fichiers.
Comme le "sous-produit" du cache de page est une page sale - ce qui a été expliqué dans l'exemple ci-dessus. Des pages sales peuvent également être observées chaque fois que l'application écrira dans un fichier ou créera un fichier - la première écriture se produira dans la zone de cache de page - créant ainsi un fichier dont le fichier de 10 Mo peut être très rapide :
# dd if=/dev/zero of=testfile.txt bs=1M count=100 10+0 records in 10+0 records out 10485760 bytes (100 MB) copied, 0,1121043 s, 866 MB/s
C'est parce que ce fichier est créé dans la région de la mémoire et non sur le disque réel - le temps de réponse est donc très rapide. Sous le système d'exploitation, une telle chose sera notée dans /proc/meminfo et plus encore dans "Dirty :
Avant que la commande ci-dessus ne soit exécutée - notez la ligne /proc/meminfo et la ligne "Dirty" :
# more /proc/meminfo | grep -i dirty Dirty: 96 kB
Après l'exécution de la commande :
# more /proc/meminfo | grep -i dirty Dirty: 102516 kB
Périodiquement, le système d'exploitation ou l'application/la base de données lancera une synchronisation qui écrira le testfile.txt réel sur le disque :
# more /proc/meminfo | grep -i dirty Dirty: 76 kB
Désormais, Oracle Database, par exemple, ne permet pas d'effectuer de telles écritures dans la région de la mémoire, comme si le système d'exploitation tombait en panne ou si le SAN LUn tombait en panne - les données seraient compromises. C'est pourquoi Oracle Database exige que les données soient "synchronisées", donc toutes les écritures doivent être confirmées par le backend comme le disque/lun avant que la base de données ne lance plus de demandes d'écriture.
Normalement, les bases de données/applications suppriment périodiquement le cache, de sorte que les pages modifiées sont écrites sur le disque en petits morceaux. Dans certains cas, la taille des pages modifiées peut augmenter, car l'application/la base de données n'a peut-être pas correctement configuré le mécanisme de cache des pages.
Ainsi, les pages modifiées peuvent écrire dans des fichiers d'échange (zone d'échange) mais également dans une région spéciale du disque (LUN/système de fichiers). Si, par exemple, nous créons plus de 100 Mo de fichier d'échange qui seront réutilisés ultérieurement à partir du fichier d'échange, nous pourrions causer des problèmes d'E/S inutiles sur le périphérique d'échange. Les systèmes d'entreprise stockent les fichiers d'échange et la zone d'échange sur le système d'exploitation sous des disques SSD ou des LUN dédiés, de sorte que les performances du disque local ne seront pas affectées (car normalement la région d'échange est créée sur le disque local)
Dans certains cas, l'application/la base de données peut avoir des problèmes en interne et les pages modifiées seront écrites en tant que fichiers d'échange mais ne seront jamais réutilisées, ce qui entraînera une augmentation de la zone d'échange et des E/S inutiles sur le disque local, ce qui entraînera une utilisation importante de l'échange sous le système d'exploitation.
Pour savoir à quel stade le système d'exploitation essaiera de renvoyer les pages modifiées sur la couche de disque, veuillez consulter la documentation officielle du noyau autour de la mémoire virtuelle ici et recherchez des paramètres tels que :
vm.dirty_background_ratio vm.dirty_ratio vm.swappiness
et
dirty_background_ratio dirty_ratio dirty_background_bytes dirty_expire_centisecs
Les paramètres ci-dessus doivent être réglés selon les exigences de la base de données/de l'application, car le système d'exploitation n'a pas de paramètre de "meilleure pratique" pour eux - ils sont réglés par charge/configuration DB/APP.
Chaque fois que l'application/la base de données exigera que les pages de mémoire soient libres sur la mémoire physique - le système d'exploitation a tendance à tout conserver dans le cache de pages - le système d'exploitation devra donc réallouer certaines pages et les marquer comme sales. Ce processus fonctionne correctement si l'extrémité de l'application/de la base de données est correctement réglée et mise à l'échelle - sinon, cela entraînera une permutation très agressive - car le système d'exploitation devra réécrire toutes les pages modifiées sur le disque d'échange - cela peut être contrôlé via le paramètre vm.swappiness.
Si l'application/la base de données effectue une permutation consensuelle, cela peut entraîner de graves écritures d'E/S sur le périphérique de permutation et entraîner de graves blocages du système. Assurez-vous toujours que l'application/les bases de données sont correctement configurées en termes de gestion de la mémoire.
Comme expliqué, toutes les pages ne seront pas marquées comme sales - la plupart des pages inutilisées seront supprimées plutôt que marquées comme sales (tout dépend si les pages déjà allouées ont été modifiées ou non)
Pour vérifier quels PID utilisent la zone d'échange, la commande ci-dessous peut être utilisée :
for file in /proc/*/status
do
awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file
done | sort -k 2 -n -r La libération de l'espace d'échange "consommé" est vraiment limitée, normalement si le PID se termine correctement ou obtient simplement l'espace d'échange d'arrêt sera récupéré, mais tuer le PID ou s'il se termine anormalement comme une erreur de segmentation peut encore laisser l'espace d'échange consommé. Une autre option consiste à redémarrer car les commandes swapoff et swapon peuvent causer de graves problèmes ou même conduire à un état de panique du système.