Bonjour,
j’utilise un Raspberry Pi 2B sous Raspian (distrib basée sur Debian Jessie) comme
passerelle à Internet depuis 4 jours, en remplacement d’un PC qui fonctionnait sous Jessie.
Je remarque une fuite de mémoire. La commande ‘free’ montre que la mémoire libre diminue et que la mémoire cache et les buffers augmentent, shared
n’évolue pas. Comment puis-je déterminer quels sont les processus qui
consomment cette mémoire ?
Merci de vos réponses.
Cette description ne correspond pas à une fuite de mémoire.
Le cache et les buffers sont alloués par le noyau, pas par des processus. Ils sont susceptibles d’occuper toute la mémoire disponible (ce serait dommage de ne rien en faire). Cette mémoire peut être libérée en cas de besoin.
Ah ben je suis rassuré, ce n’est pas une fuite de mémoire mais la quantité de mémoire disponible diminue quand même.
Et comment se fait il que le noyau alloue de la mémoire ? Il le fait de sa propre initiative sans doute. A croire que la mémoire utilisée par le noyau ne correspond en rien à l’activité de la bécane.
La quantité de mémoire disponible ne diminue pas vraiment puisque la majeure partie de la mémoire occupée par les buffers et le cache peut être libérée en cas de besoin. C’est la quantité de mémoire libre ou inutilisée qui diminue. La quantité de mémoire réellement disponible est évaluée dans la deuxième colonne, soit environ 630 Mio et non 350 Mio dans l’exemple ci-dessous.
$ free
total used free shared buffers cached
Mem: 1033080 677748 355332 0 31164 249960
-/+ buffers/cache: 396624 *636456*
Swap: 977916 836 977080
Le noyau n’alloue pas de la mémoire pour le cache ou les buffers de sa propre initiative, il le fait en fonction de l’activité des processus. Quand un processus demande à lire un fichier, le noyau le lit depuis le système de fichiers stocké sur un périphérique de stockage et en garde une copie en cache. Quand un processus écrit des données, celles-ci sont stockées dans des buffers avant d’être effectivement envoyées sur le péripérique de stockage.
Ce qu’il faut vérifier, c’est l’activité du swap.
Et quand la bécane n’est pas sollicité de toute une nuit, qu’en début de nuit la quantité de mémoire libre est de l’ordre de 60% et qu’en fin de nuit elle n’est plus que de l’ordre de 45%, que la quantité de mémoire cache a augmenté de ce que la quantité de mémoire libre a dimniué, tu en tires quoi comme conclusion ?
Vérifier l’activité du swap sur un Raspberry Pi, ça va être vite vu…
Sur un autre forum, on m’a répondu en 2 lignes. Tu peux continuer à broder sur le sujet et à jouer sur les mots si ça t’amuse.
Qu’une tâche périodique (cronjob) qui fait des accès au système de fichiers s’est déclenchée pendant la nuit. Chez moi par exemple il y a diverses indexations de fichiers, le nettoyage du cache APT d’approx…
Non sollicitée ne signifie pas qu’elle ne fait rien.
Ah, pardon de la méprise, je croyais que tu cherchais à comprendre.
Par curiosité, que t’a-t-on répondu sur l’autre forum ?
Si c’est un lien qui pointe vers une page qui décrit la gestion de l’allocation de la mémoire par le noyau, effectivement ça tient en une ligne.
Une information qui peut être utile si le système utilise tmpfs (système de fichiers temporaire en mémoire) pour /tmp ou autre : les fichiers écrits dans un système de fichiers tmpfs occupent de la mémoire allouée au cache. En fait ce n’est pas spécifique à tmpfs et concerne tous les types de systèmes de fichiers comme ext4 ( C’est toute l’élégance de tmpfs d’exploiter des structures existantes), mais la particularité de tmpfs est que les données en cache ne sont pas ensuite écrites sur le périphérique de stockage puisque celui-ci n’existe pas. En contrepartie elles peuvent être envoyées dans le swap s’il existe.
Bref, si un processus crée des fichiers dans un tmpfs et ne les efface pas, cela occupe de la mémoire, au lieu d’occuper de l’espace disque avec un système de fichiers classique. Mais ce n’est pas une fuite de mémoire. La terminaison du processus responsable ne libère pas cette mémoire, mais on peut la libérer en supprimant les fichiers s’ils ne sont plus ouverts.
Note : les répertoires montés en tmpfs “en standard” tels que /dev, /run ne sont normalement pas concernés car ils sont de petite taille et n’ont pas vocation à contenir de grandes quantités de données.
Il y a un point que tu sembles avoir complètement négligé : il s’agit d’une Raspberry Pi. C’est à dire, petit CPU, peu de RAM non extensible, pas de disque dur ou de SSD mais le fs est sur une carte mémoire micro SD.
Plus de 15 ans de Linux, plus de 25 ans d’informatique en professionnel, plus de 35 ans d’informatique tout compris, merci de m’apprendre que “non sollicité ne signifie pas qu’elle ne fait rien”… Aurais tu travaillé chez Microsoft ? Si les informations que tu donnes sont techniquement correctes (et encore, ton subtil distingo entre mémoire libre et mémoire disponible est du grand n’importe quoi), elles n’ont aucun intérêt.
La réponse qu’on m’a donné n’est pas un lien vers la gestion de la mémoire par le noyau. La première ligne est une explication qui confirme mon diagnostic, et la deuxième ligne est la commande qui permet de contrecarrer le phénomène. Ce n’est pas exactement ce que je demandais mais ça me convient.
La commande est celle-ci :
sudo /bin/sh -c “/bin/sync; /bin/echo 3 > /proc/sys/vm/drop_caches” >/dev/null 2>&1
De plus, j’ai mis en oeuvre cette solution sur mon autre bécane sous XUbuntu, qui malgrè ses 16 Go de RAM, commençait à swapper au bout d’une dizaine d’heures d’utilisation. Après 48H, l’utilisation du swap était assez importante. Maintenant, cette machine ne swappe plus.
Certes je n’ai pas d’expérience avec cette plate-forme, mais si j’en crois Wikipédia le Raspberry Pi 2B a quand même 1 Go de RAM, autant que mon PC portable sous Debian qui me suffit pour une utilisation bureautique et internet standard. D’autre part, “peu de RAM”, c’est relatif : il faut le comparer à l’utilisation de la machine.
S’il te plaît, épargne-moi les arguments d’autorité. Apparemment, jusqu’ici ta longue expérience n’avait pas suffi à te faire connaître l’utilisation du paramètre vm.drop_caches.
Tu semblais t’étonner que la machine soit dans un état différent de celui dans lequel tu l’avais laissée alors que tu ne lui avais rien demandée, alors dans le doute…
Non, la différence peut sembler subtile mais est réelle.
La mémoire “libre” n’est pas allouée et ne contient rien.
La mémoire “disponible” est allouée et contient des copies de données qui existent ailleurs, elle peut donc être libérée assez facilement en cas de besoin.
D’après toi, à quoi sert la seconde ligne de valeurs dans la sortie de la commande free ?
Puis-je connaître la teneur de cette explication qui confirme ton diagnostic de fuite de mémoire ? L’“efficacité” de la commande proposée infirme au contraire l’hypothèse d’une fuite de mémoire. vm.drop_cache ne libère que de la mémoire libérable, ce qui n’est pas le cas d’une fuite.
Au passage tu auras peut-être constaté une baisse de réactivité à la suite de son exécution, car le fait de vider les caches oblige le noyau à recharger les fichiers (exécutables et données) des commandes courantes depuis la carte SD lors des commandes suivantes.
Qu’entends-tu exactement par “utilisation du swap importante” ?
S’agit-il de la quantité de swap occupée affichée par free ou bien de son activité de déchargement et rechargement de pages mémoire (affichée par vmstat <période>) ?
Si c’est la performance globale du système qui t’importe, ce n’est pas la quantité de swap occupé que tu dois regarder mais son activité.
Il est naturel qu’après un temps d’utilisation le noyau commence à swapper les portions de mémoire allouées mais inutilisées (ce qui peut inclure de vraies fuites mémoire, pour le coup). C’est bénéfique pour les performances : il vaut mieux libérer la mémoire pour pouvoir la réaffecter à un usage plus “productif” que d’y laisser des données auxquelles personne n’accède.
Ce mécanisme est ajustable avec le paramètre vm.swappiness qui règle la tendance du noyau à swapper entre 0 et 100. Par défaut sa valeur est de 60, et dans certains cas elle peut conduire à trop favoriser le cache au détriment des processus. On peut régler une valeur plus basse.
S’il te plaît, pour une fois, épargne nous ta prétention, ton arrogance, ta suffisance et ton mépris des autres.
C’est une grande différence entre toi et moi. Contrairement à toi, je sais que je ne sais pas tout.
Mauvaise analyse de ta part, et ce n’est pas la seule. Ton arrogance et ta prétention t’aveuglent.
Mais je t’en prie, continue à étaler ta science…
Non, cela t’instruirait (il faut de la culture pour bien apprécier cette répartie).
Inscrit il y a 2 jour il commence déjà a insulter les autres membres 
Fanfaronner qu’un autre forum a donner la «réponse qu’il voulait» sans le cité ni dire exactement la réponse tu fait fort.
Si c’est
$ echo 3 > /proc/sys/vm/drop_caches
ou
sudo sysctl -w vm.drop_caches=3
et que ça te suffit, grand bien t’en fait.