Pour moi, non.
Les programmes et bibliothèques qui sont placés en swap sont ceux qui sont les moins utilisés.
Si tu veux savoir quelle application sature la mémoire il faut surveiller son occupation au cours du temps.
Il est incorrect de dire qu’un processus abuse du swap. Un processus ne voit que sa mémoire virtuelle, il ne sait pas si une page est en RAM, en swap, les deux (swapcache), mappée à partir d’un fichier (notamment binaire exécutable ou bibliothèque) ou pas allouée du tout (jamais utilisée). Il peut seulement demander qu’une page ne soit pas swappée, par exemple parce qu’elle contient des données sensibles (clé secrète…) qui ne doivent pas être écrites dans le swap.
Pour dire s’il s’agit d’une fuite de mémoire, il faut savoir si cette occupation mémoire est normale ou non, si elle augmente avec l’uptime ou pas…
Je ne sais pas à quoi sert akonadiserver, mais 1,4 Go de mémoire ça me paraît quand même beaucoup. Ce qui est curieux, c’est que le processus occupe très peu de mémoire résidente en comparaison (25 Mo) donc soit il n’utilise jamais les données qui sont en swap (et il peut s’agir de fuite), soit il est lui-même inactif. Même remarque pour mysqld.
Que LibreOffice ait desfuites de mémoire, ça ne me choque pas vraiment de la part d’une usine à gaz qui n’a pas vocation à tourner en permanence.
En première approximation on peut additionner RES+SWAP, mais ça reste une approximation. La gestion de la mémoire est quelque chose d’extrêmement complexe en partie à cause de toutes les optimisations mises en oeuvre, et il est difficile d’évaluer la quantité de mémoire occupée par un processus. Une partie de la mémoire résidente peut être à la fois en RAM et dans le swap (swapcache), partagée avec d’autres processus (mémoire partagée, bibliothèques partagées, fichiers mappés…)
Non, ce n’est pas « que du cache » qu’on peut jeter à tout moment. Comme je l’ai écrit, le cache contient aussi tous les fichiers mappés dans la mémoire virtuelle des processus, ce qui inclut notamment les portions des binaires exécutables et les bibliothèques partagées qu’ils utilisent. J’ignore dans quelle mesure cette partie du cache est récupérable. Il y a aussi le contenu « sale » (modifications du système de fichiers en attente d’écriture sur disque) mais il me semble qu’un sync devrait le réduire.
Aussi, par défaut depuis Debian stretch free additionne le cache et les buffers dans une même colonne. En général le cache est bien plus gros que les buffers, mais ces derniers peuvent grossir lorsqu’il y a de l’activité disque. Pour les afficher séparément il faut ajouter l’option -w.
Désolé d’insister mais le premier retour montre bien qu’il y a un problème avec signal-desktop.
4682 turman 20 0 37,2g 288500 68592 S 24,8 3,6 7719:45 signal-desktop
Je ne suis pas assez calé en matière de gestion de la mémoire, mais AMHA le fait qu’une application utilise le swap n’indique en rien qu’elle présente une fuite mémoire.
Pour moi, si une application présente une fuite mémoire elle va réclamer de la RAM sans en libérer et le système va déplacer les pages mémoire peu ou pas utilisées vers le swap, donc a priori celle des autres applications .
Si tu fais allusion aux 37 Go de mémoire virtuelle, je t’accorde que ça me paraît complètement délirant mais ça reste de la mémoire virtuelle, donc potentiellement du vide. La mémoire résidente n’est « que » de 288 Mo et on ne voit pas le swap.
Certes, mais ça peut être un signe, surtout si les données mises en swap n’en sortent jamais, signe que le processus ne les utilise pas.
Dans un premier temps, oui. Ensuite quand le système va à nouveau avoir besoin de réclamer de la mémoire, il va voir que les pages liées à la fuite ne sont jamais utilisées et les swapper à leur tour.
Oui c’est bien à cela que je faisais allusion.
J’ai regardé sur une machine de bureau et j’ai trouvé un processus (Firefox webextensions) qui occupe plus de 24 Go de mémoire virtuelle.
Ce n’est donc pas exceptionnel. Mais j’ai du mal à comprendre ce concept de mémoire virtuelle et la page de man de top en donne une explication plus que succincte.
Merci pour tes explications complémentaires.
Concernant akonadi je l’utilise depuis des années (c’est un composant de kmail/kontact) et je n’ai jamais constaté de fuite mémoire.
La mémoire virtuelle est avant tout un concept, un mode de fonctionnement des processeurs et systèmes d’exploitation « modernes » comme Linux, qui permet l’isolation des processus et la gestion efficace de la mémoire. Chaque processus « voit » un espace d’adressage virtuel indépendant des autres processus et de l’espace d’adressage de la mémoire physique (autrement dit, le contenu de la mémoire à l’adresse X d’un processus n’a potentiellement rien à voir avec le contenu de la mémoire à la même adresse d’un autre processus ou de la mémoire physique).
Dans cet espace d’adressage virtuel, le noyau « mappe » tout ce dont le processus a besoin :
- le programme exécutable
- les bibliothèques partagées
- les fichiers de données mappés en mémoire (moyen alternatif aux entrées-sorties classiques pour l’accès à un fichier, cf. mmap)
- la mémoire de travail du processus
- les données swappées
- la mémoire partagée avec d’autres processus à des fins de communication ou synchronisation
j’en oublie peut-être d’autres
Tout cela constitue ce qui est compté comme la mémoire virtuelle. Cependant l’occupation réelle peut être inférieure car seules les zones de mémoire de travail ou des fichiers mappés auxquelles le processus a accédé occupent réellement de la mémoire. En effet le noyau alloue la mémoire pour une page donnée seulement lors du premier accès à celle-ci. Cela évite les entrées-sorties (dans le cas d’un fichier mappé) et les allocations de mémoire inutiles. D’autre part le noyau fait de l’« overcommit » : il peut allouer plus de mémoire virtuelle qu’il n’y a de mémoire physique disponible, en pariant sur le fait que les processus n’utiliseront pas toute la mémoire qu’ils ont demandée.
2 J'aime
Merci pour ces infos, c’est très intéressant.
Après avoir donc fermé les applications qui consommaient le plus de swap je me retrouve dans un état pas trop mal:
total used free shared buff/cache available Mem: 7.7Gi 3.2Gi 840Mi 1.5Gi 3.6Gi 2.6Gi Swap: 7.9Gi 403Mi 7.5Gi
Je suis bien content d’avoir cette astuce pour voir la swap consommée par processus dans top, et du coup pouvoir estimer la taille de mémoire occupée par chacun d’entre eux en additionnant swap+ res. C’est pas ultra pratique mais il doit y avoir moyen de configurer top pour au moins avoir l’affichage de la colonne swap par défaut.
Pour revenir à mes différentes sorties de free j’ai quand même une question ultra basique: pourquoi total != used + free ? Dans mon cas on dirait qu’il faut rajouter buffer/cache pour arriver au total mais pour moi used est censé contenir tout ce qui n’est pas free, y compris le buffer/cache.
C’est la définition même de la valeur « used » figurant dans la page de manuel de free:
used Used memory (calculated as total - free - buffers - cache )
Effectivement. J’ai été feinté par la page postée plus haut où on peut voir cette sortie de free où total = used + free:
$ free -m total used free shared buff/cache available Mem: 1504 1491 13 0 855 792 Swap: 2047 6 2041
Surprenant n’est ce pas ?
Oui, ça correspond à la valeur de « used » affichée par les anciennes versions de free. Mais celles-ci n’affichaient pas de colonne « available » ni de colonne « buff/cache » combinée :
total used free shared buffers cached
Mem: 1,5G 1,2G 258M 44M 47M 351M
-/+ buffers/cache: 853M 657M
Swap: 954M 240M 714MIntéressant, ça marche sur htop ?
(j’ai appuyé sur f et ça n’a rien donné)
Mais dans l’exemple de la page on dirait que c’est la version récente de free puisqu’on voit bien la colonne « available » ainsi que la colonne « buff/cache » combinée, le tout sur la ligne de « Mem: » 
Bonjour,
Une fois l’affichage de la colonne swap configurée, faire Maj+w dans la fenêtre normale de top pour sauvegarder la config dans le fichier ~/.toprc
A+
1 J'aime
Je ne connais pas htop. Apparemment il faut passer par F2/Setup pour configurer les colonnes à afficher. Mais je ne vois pas la quantité de swap utilisée parmi les colonnes disponibles dans la page de manuel de buster. Elle ne fait son apparition que dans la version de testing/sid, mais c’est peut-être la page de manuel qui n’était pas à jour, ça peut arriver.
Oui, j’ai vu. Cependant la sortie des commandes free dans la page de tests dont le lien figure à la fin du document correspond bien à l’ancien format. Il se peut que la première page ait été mise à jour de façon incomplète pour prendre en compte le nouveau format. On peut voir que les deux formats cohabitaient dans la version initiale de la page importée dans github.
1 J'aime
Merci, c’est top ! 
Bien vu, on avait donc un mix des anciennes et nouvelles versions de free, forcément ça pouvait prêter à confusion. En tout cas ok, dans les versions récentes, la partie « used » n’englobe pas le « buff/cache » malgré son nom, alors que c’était le cas avant.
Pour revenir à ma situation, là maintenant free me renvoie:
total used free shared buff/cache available Mem: 7.7Gi 4.3Gi 596Mi 1.5Gi 2.8Gi 1.6Gi Swap: 7.9Gi 1.3Gi 6.7Gi
Rien de très anormal, c’est juste un peu frustrant d’avoir un aussi gros cache/buffer avec seulement une gros tiers qui est « récupérable » (1 Gb sur 2.8 Gb).
Cela dépasse les limites de mes connaissances. Peut-être plus d’indices dans /proc/meminfo dont free n’affiche qu’un extrait.
J’avoue qu’à un moment j’avais un petit doute sur l’existence de ces limites 
C’est sans doute ce qui explique les valeurs très élevées observées pour VIRT.
Et c’est la même pour les applications Rocket tchat et Zoom que j’utilise souvent sur mon poste de travail … 
j’utilise atop
touche m pour la mémoire
