Utilisation très élevée du cache provoquant un ralentissement
J'essaie d'identifier le coupable de ce qui rend mon ordinateur extrêmement lent. Le plus gros suspect est la mémoire. Lorsque l'ordinateur fonctionne rapidement, ma mémoire cache semble normale. Cependant, quand il fonctionne lentement, il ressemble à ceci:
luke@Luke-XPS-13:~$ free -m
total used free shared buff/cache available
Mem: 7830 1111 1090 277 5628 1257
Swap: 16077 665 15412
et ça:
luke@Luke-XPS-13:~$ vmstat -S M
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 665 1065 67 5562 0 0 34 88 43 23 13 4 82 0 0
Les caches occupent 5,5 Go de ma mémoire de 8 Go, lorsque tous les programmes sont fermés et après exécution
echo "echo 3 > /proc/sys/vm/drop_caches"
qui devrait être la force de les effacer. Dès que l'ordinateur commence à piocher dans le swap, son jeu est remplacé par une vitesse utilisable. L'arrêt corrige temporairement le problème, mais il finit par revenir et je ne peux pas comprendre ce qui le cause. Slabtop en révèle un peu plus sur le coupable, mais je ne suis pas sûr de ce que cela implique. Pourquoi kmalloc-4096?
Active / Total Objects (% used) : 1554043 / 1607539 (96.7%)
Active / Total Slabs (% used) : 167569 / 167569 (100.0%)
Active / Total Caches (% used) : 76 / 109 (69.7%)
Active / Total Size (% used) : 5091450.96K / 5105920.97K (99.7%)
Minimum / Average / Maximum Object : 0.01K / 3.18K / 18.50K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
1254755 1254755 100% 4.00K 156847 8 5019104K kmalloc-4096
5430 5430 100% 2.05K 362 15 11584K idr_layer_cache
20216 9010 44% 0.57K 722 28 11552K radix_tree_node
8820 7358 83% 1.05K 294 30 9408K ext4_inode_cache
38577 25253 65% 0.19K 1837 21 7348K dentry
12404 11432 92% 0.55K 443 28 7088K inode_cache
30120 29283 97% 0.20K 1506 20 6024K vm_area_struct
31722 31722 100% 0.12K 933 34 3732K kernfs_node_cache
13696 12514 91% 0.25K 856 16 3424K kmalloc-256
27144 27134 99% 0.10K 696 39 2784K buffer_head
41088 29789 72% 0.06K 642 64 2568K kmalloc-64
632 567 89% 3.75K 79 8 2528K task_struct
2432 2274 93% 1.00K 152 16 2432K kmalloc-1024
3048 2677 87% 0.64K 127 24 2032K shmem_inode_cache
912 845 92% 2.00K 57 16 1824K kmalloc-2048
172 162 94% 8.00K 43 4 1376K kmalloc-8192
1736 1561 89% 0.56K 62 28 992K ecryptfs_key_record_cache
5103 4073 79% 0.19K 243 21 972K kmalloc-192
1792 1626 90% 0.50K 112 16 896K kmalloc-512
1456 1456 100% 0.61K 56 26 896K proc_inode_cache
10149 8879 87% 0.08K 199 51 796K anon_vma
24960 19410 77% 0.03K 195 128 780K kmalloc-32
360 352 97% 2.06K 24 15 768K sighand_cache
D'après vos commentaires, vous dites que l'utilisation du cache ne diminue pas de façon notable lorsque vous essayez de echo 3 > /proc/sys/vm/drop_caches
Cela ne peut se produire que s'il s'agit d'un cache pour l'écriture. Si vous écrivez 5 Go dans certains fichiers, les données arrivent immédiatement en cache et votre programme se poursuit. Le cache est en fait écrit dans le stockage en arrière-plan aussi rapidement que possible. Dans votre cas, le stockage semble considérablement ralenti et vous accumulez le cache non écrit jusqu'à ce qu'il draine tout votre RAM et commence à tout pousser pour être échangé.
Le noyau n'écrira jamais le cache sur la partition d'échange. Il le conserve dans RAM jusqu'à ce qu'il soit écrit en toute sécurité dans la destination.
Le noyau ne supprimera jamais le cache non écrit, car ce serait une perte de données (vous avez enregistré un fichier, vous vous attendez donc à ce que les données arrivent sur le stockage permanent).
Vous ne pouvez le résoudre qu'en accélérant le stockage. Ce problème survient souvent sur des supports de stockage montés via le réseau (vérifiez votre mount pour les types cifs, nfs, sshfs, etc.) ou des périphériques USB1 lents.
Vous pouvez également rendre le problème beaucoup moins dramatique pour le système en plafonnant le cache encrassé avec sysctl vm.dirty_ratio=10 avant qu'il ne grossisse trop.
sale_ratio
Contient, en pourcentage de la mémoire totale disponible contenant des pages libres et des pages récupérables, le nombre de pages auxquelles un processus générant des écritures sur disque commencera lui-même à écrire des données altérées.
La mémoire totale disponible n'est pas égale à la mémoire totale du système.
Si le diagnostic est correct, vous verrez que le cache peut être facilement supprimé (au moins 90% de celui-ci) et que le processus qui écrit ces gigaoctets devient très lent. Le reste du système deviendra plus réactif.
La mémoire disponible est allouée au cache disque. C'est normal.
La lenteur causée par l'utilisation de swap est également normale. Cela dit, votre échange est environ le double de la taille nécessaire.
Vous pouvez essayer de définir le paramètre vm.swappiness pour essayer d’équilibrer l’utilisation du cache swap par rapport au cache disque.
Immédiatement après un redémarrage, pour l’essayer à la volée, dans un type terminal:
Sudo sysctl -w vm.swappiness=10
Si cela vous aide, rendez-le permanent en modifiant:
gksudo gedit /etc/sysctl.conf
et en ajoutant:
# adjust swap vs ram ratio, default=60
vm.swappinesss=10
à la fin du fichier, enregistrez et quittez, redémarrez.