web-dev-qa-db-fra.com

La mémoire est pleine au fil du temps, utilisation élevée du "tampon / cache", faible mémoire "disponible"

Chaque fois que je redémarre mon ordinateur portable, tout fonctionne à merveille et j'ai un maximum de 40% d'utilisation de la mémoire (sur 8 Go). Cependant, au fil du temps (~ 1 jour d'utilisation), l'utilisation de la mémoire augmente jusqu'à 90% et le système commence à échanger.

Maintenant, free -mh renvoie ceci:

              total        used        free      shared  buff/cache   available
Mem:           7,7G        1,3G        141M        223M        6,3G        246M
Swap:          7,5G        530M        6,9G

Je supposais que la mémoire tampon/cache est libre d'être réallouée si les processus l'exigent, mais elle semble surtout indisponible.

cat /proc/meminfo:

MemTotal:        8055268 kB
MemFree:          145184 kB
MemAvailable:     247984 kB
Buffers:           49092 kB
Cached:           423724 kB
SwapCached:        38652 kB
Active:           881184 kB
Inactive:         791552 kB
Active(anon):     708420 kB
Inactive(anon):   725564 kB
Active(file):     172764 kB
Inactive(file):    65988 kB
Unevictable:         252 kB
Mlocked:             252 kB
SwapTotal:       7812092 kB
SwapFree:        7267624 kB
Dirty:               352 kB
Writeback:             0 kB
AnonPages:       1195320 kB
Mapped:           235860 kB
Shmem:            234068 kB
Slab:            6117796 kB
SReclaimable:     167260 kB
SUnreclaim:      5950536 kB
KernelStack:       10352 kB
PageTables:        30312 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    11839724 kB
Committed_AS:    6410728 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:    104448 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1361472 kB
DirectMap2M:     5859328 kB
DirectMap1G:     1048576 kB

J'ai trouvé ces valeurs particulièrement intéressantes, car elles sont fortement corrélées avec l'utilisation de buff/cache de free, mais je ne sais pas quoi en faire ni où chercher ensuite:

SReclaimable:     167260 kB
SUnreclaim:      5950536 kB
Slab:            6117796 kB

Où puis-je regarder ensuite? Qu'est-ce que la dalle et existe-t-il un moyen de réduire son utilisation de la mémoire?

ubuntumemoryout-of-memory
6
Max Hollmann

Vous devez vérifier avec top si quelque chose utilise réellement votre RAM ou non, trier par utilisation de la mémoire ou vérifier l'utilisation de la mémoire dans le Moniteur système.

Linux empruntera de la mémoire inutilisée pour la mise en cache du disque. Cela donne l'impression que vous manquez de mémoire, mais vous ne l'êtes pas. Consultez cette page Web pour plus d'explications: https://www.linuxatemyram.com/

Vous avez en fait environ 6,5 Go de mémoire inutilisée sur l'exemple qui a été publié. Vous pouvez également constater que le montant du swap est très faible (540 Mo).

Vous pouvez libérer le (s) cache (s) comme expliqué ici puis free vous affichera la mémoire libre dans le champ disponible:

  • Pour libérer la pagecache:

    # echo 1 > /proc/sys/vm/drop_caches

  • Pour libérer des dentiers et des inodes:

    # echo 2 > /proc/sys/vm/drop_caches

  • Pour libérer la pagecache, les dentiers et les inodes:

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

Ou avec cette commande:

free && sync && echo 3 > /proc/sys/vm/drop_caches && free

Concernant la dalle:
Dalle, SR récupérable, SU récupéré
Le noyau fait beaucoup de répétitions pendant son exécution. Certains objets, comme demander l'inode spécifique d'un fichier, peuvent être exécutés des milliers de fois par jour. Dans un tel cas, il serait sage de le stocker dans une liste de référence rapide ou un cache. Les dalles sont les caches des objets du noyau, pour optimiser les activités qui se produisent le plus.

Le champ Slab est le total de SReclaimable et SUnreclaim.

Essayez de résoudre ce qui utilise la quantité de mémoire Slab SUnreclaim avec slabtop.

Les éléments ci-dessus sont destinés à être exécutés en tant que root.

4
mazs

Donc, après un peu d'ingénierie dépannage , j'ai découvert que xflux semble être à l'origine du kmalloc-4096 dalle à croître lentement mais régulièrement. J'essaierai de découvrir pourquoi et de mettre à jour cette réponse.

2
Max Hollmann