Je vois surtout le swap qui se remplit. Fuite de mémoire ?
Bonjour,
Effectivement il y a un gros usage du swap. Parmi les applications visibles dans le retour de la commande top, signal-desktop est un coupable idéal :
On peut ajouter l’affichage de l’utilisation du swap par chaque processus dans top.
Appuyer sur f pour entrer dans la gestion de champs.
Descendre le curseur sur « SWAP ».
Appuyer sur d pour le sélectionner comme colonne à afficher.
Appuyer sur flèche droit puis flèche haut pour déplacer le champ à côté de RES.
Appuyer sur Entrée pour valider la position.
Appuyer sur s pour trier sur la colonne.
Appuyer sur q pour revenir à l’affichage des processus.
1 J'aime
Effectivement il y a aussi l’occupation du swap qui me parait également énorme puisque 7 Gb utilisé.
J’ai fermé signal-desktop et voici le retour de free maintenant:
total used free shared buff/cache available
Mem: 7.7Gi 3.4Gi 1.4Gi 1.4Gi 2.9Gi 2.6Gi
Swap: 7.9Gi 6.2Gi 1.7Gi
On voit que ça a libéré un peu de mémoire swap mais pas tant que ça (et j’ai toujours ces 3 Gb de buff/cache qui ne descendent jamais).
Il serait effectivement intéressant de voir qui utilise le swap, voici l’affichage de top suite à la manip de Pascal:
top - 12:23:42 up 31 days, 14:37, 8 users, load average: 1.34, 1.56, 1.14 Tasks: 303 total, 1 running, 302 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.3 us, 3.6 sy, 0.0 ni, 91.1 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st MiB Mem : 7849.2 total, 1182.9 free, 3786.9 used, 2879.3 buff/cache MiB Swap: 8131.0 total, 1940.0 free, 6191.0 used. 2130.6 avail Mem PID USER PR NI VIRT RES SWAP SHR S %CPU %MEM TIME+ COMMAND 1435 turman 20 0 4310812 25400 1.4g 2136 S 0.0 0.3 95:29.19 akonadiserver 8262 turman 20 0 7747656 269468 682904 86044 S 0.0 3.4 249:18.34 soffice.bin 1315 turman 20 0 4907900 246984 558636 49460 S 2.0 3.1 2451:07 plasmashell 1872143 turman 20 0 8515492 186336 438120 30676 S 0.3 2.3 47:11.93 skrooge 2077 turman 20 0 2436240 31356 378700 6824 S 0.3 0.4 74:17.12 akonadi_imap_re 1646 turman 20 0 3084824 24800 317596 5788 S 0.0 0.3 165:43.86 mysqld 1414 turman 20 0 4505236 197592 298212 12520 S 0.3 2.5 132:16.27 nextcloud 2554621 turman 20 0 3570676 365612 144260 157000 S 0.3 4.5 81:41.29 Web Content 893 root 20 0 1880328 284384 92856 242804 S 11.6 3.5 437:26.72 Xorg 2542576 turman 20 0 5194452 836596 81948 313728 S 1.7 10.4 351:56.15 firefox-esr 2785799 turman 20 0 3826556 728268 75304 340244 S 1.0 9.1 28:33.86 Web Content 2555128 turman 20 0 3723112 146644 65540 68072 S 0.0 1.8 1:46.97 kontact 2542695 turman 20 0 3440640 263960 55964 125736 S 0.3 3.3 39:28.65 Web Content 2542640 turman 20 0 3251472 279924 52240 78764 S 0.3 3.5 103:11.17 Web Content 1351 turman 20 0 2256544 56504 51432 10224 S 0.0 0.7 42:07.65 korgac 2542669 turman 20 0 3247892 248736 50744 76100 S 1.0 3.1 46:26.70 Web Content 2093 turman 20 0 522104 5152 49172 1348 S 0.0 0.1 8:46.31 akonadi_notes_a 2542714 turman 20 0 3015168 224700 39724 146448 S 0.0 2.8 31:03.29 Web Content 2542740 turman 20 0 3251100 201432 37248 121156 S 0.0 2.5 9:38.42 Web Content 1233 turman 20 0 3992912 84120 34160 25192 S 8.3 1.0 351:18.23 kwin_x11 3032431 turman 20 0 2140740 34924 32532 26048 S 0.0 0.4 0:07.54 kinfocenter 1421489 turman 20 0 1676076 80420 32496 45564 S 0.3 1.0 5:45.12 dolphin 2081 turman 20 0 1141524 5704 28488 3944 S 0.0 0.1 1:41.15 akonadi_mailfil 2098 turman 20 0 1066752 2132 25840 1176 S 0.0 0.0 1:33.56 akonadi_unified 1538 turman 20 0 249064 11404 25320 5332 S 0.0 0.1 28:46.11 wicd-client 2074 turman 20 0 1141324 5520 24404 1936 S 0.0 0.1 1:41.97 akonadi_archive 1716 turman 20 0 1298172 6288 23604 2824 S 0.0 0.1 0:25.87 kwalletd5 1356 root 20 0 364164 9596 22724 2744 S 0.0 0.1 2:08.76 packagekitd 2078 turman 39 19 402876 8000 22060 5040 S 0.0 0.1 2:22.27 akonadi_indexin
C’est très intéressant !
Akanodiserver est connu pour ses fuites mémoires, d’habitude j’ai même un script qui le redémarre toutes les heures mais là j’avais oublié de le lancer. En tuant le process j’ai récupéré carrément 2 Gb de swap (alors que top disait qu’il n’utilisait « que » 1.4 Gb):
total used free shared buff/cache available
Mem: 7.7Gi 3.6Gi 1.4Gi 1.6Gi 2.7Gi 2.2Gi
Swap: 7.9Gi 4.1Gi 3.9Gi
Après avoir quitté LibreOffice (soffice.bin était le 2e process qui utilisait le plus de swap) j’ai récupéré 600 Mb en plus de swap, ce qui pour le coup correspondait bien à l’affichage de top:
total used free shared buff/cache available
Mem: 7.7Gi 3.5Gi 1.5Gi 1.5Gi 2.7Gi 2.4Gi
Swap: 7.9Gi 3.4Gi 4.5Gi
Donc ok, au bout d’un mois dans reboot, j’avais donc quelques process qui abusaient clairement de la mémoire swap. J’imagine que l’on peut parler de fuite mémoire pour Akonadi ou LibreOffice.
Mais ça veut donc dire que l’espace swap utilisé par les processus ne se visualise pas dans la colonne « mémoire » de l’activité système de KDE (ksysguard) où aucun process ne dépassent les 500 Mb. A croire qu’il ne compte que la mémoire résidente en mémoire physique, toute comme la colonne RES de top (les valeurs sont un peu différentes quand même). C’est dommage qu’il n’y ait pas un moyen simple de voir toute la mémoire vraiment utilisée par les processus, quelle soit en RAM ou en swap.
La bonne nouvelle c’est que maintenant 2.4 Gb sont available pour 1.5 Gb de free. Une partie importante de buff/cache semble donc maintenant être « récupérable » (près de 1 Gb sur 2.7 Gb). Mais je ne comprend toujours pas pourquoi ça ne serait pas l’intégralité (ou presque) qui pourrait être récupérable puisque ça n’est que de la cache…
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.