4 votes

Utilisation très élevée du cache entraînant un ralentissement

Je tente d'identifier le coupable de ce qui cause l'extrême lenteur de mon ordinateur personnel. Le principal suspect est la mémoire. Lorsque l'ordinateur fonctionne rapidement, ma mémoire cache semble normale. Cependant, lorsqu'il fonctionne lentement, cela 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 ceci:

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 consomment 5,5 Go de mes 8 Go de mémoire, lorsque tous les programmes sont fermés, et après avoir exécuté

echo "echo 3 > /proc/sys/vm/drop_caches"

qui devrait les vider de force. Dès que l'ordinateur commence à basculer dans le swap, c'est la fin de la vitesse utilisable. L'arrêt temporaire résout le problème, mais il revient inévitablement et je n'arrive pas à comprendre ce qui le provoque. Slabtop révèle légèrement 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

6voto

nttakr Points 964

Basé sur vos commentaires, vous dites que l'utilisation du cache ne diminue pas de manière significative lorsque vous essayez d'exécuter echo 3 > /proc/sys/vm/drop_caches

Cela ne peut se produire que s'il s'agit d'un cache d'écriture. Si vous écrivez 5 Go dans certains fichiers, les données atterrissent immédiatement dans le cache et votre programme continue. Le cache est en réalité écrit sur le stockage en arrière-plan aussi rapidement que possible. Dans votre cas, le stockage semble très lent et vous accumulez le cache non écrit jusqu'à ce qu'il épuise toute votre RAM et commence à tout transférer vers le swap.

Le noyau ne déplacera jamais le cache vers la partition de swap. Il le garde en RAM jusqu'à ce qu'il soit écrit en toute sécurité vers sa destination.

Le noyau ne laissera jamais tomber le cache non écrit, car ce serait une perte de données (vous avez enregistré un fichier, donc vous vous attendez à ce que les données arrivent sur le stockage permanent).

Vous ne pouvez résoudre ce problème qu'en accélérant le stockage. Ce problème est souvent observé sur un stockage monté via un réseau (vérifiez votre mount pour les types cifs, nfs, sshfs, etc.) ou sur des périphériques USB1 lents.

Vous pourriez également rendre le problème beaucoup moins dramatique pour le système en limitant le cache sale avec sysctl vm.dirty_ratio=10 avant qu'il ne devienne trop important.

dirty_ratio

Contient, en pourcentage de la mémoire totale disponible contenant des pages libres et des pages réclamables, le nombre de pages à partir duquel un processus qui génère des écritures sur disque commencera lui-même à écrire des données sales.

La mémoire totale disponible n'est pas égale à la mémoire totale du système.

Si c'est un diagnostic correct, vous verrez que le cache peut être facilement supprimé (au moins 90 %) et que le processus qui écrit ces gigaoctets devient très lent. Le reste du système deviendra plus réactif.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X