Connaître la consommation mémoire d’un processus

Cet article a été publié il y a 9 ans 1 mois 27 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Après une discussion sur Twitter à propos de la consommation de mémoire de MariaDB « out-of-the-box » (au final MySQL consomme pareil), s’est posée la question de savoir comment afficher la quantité de mémoire utilisée par un seul processus. Pas évident, mais pas impossible.

Attention : je suis loin d’être un expert dans le domaine du noyau Linux, et encore moins de la gestion de la mémoire vive. Donc si je dis d’énormes bêtises qu’il faut corriger, faites-moi signe.

De multiples valeurs possibles

Mémoire virtuelle, mémoire partagée, mémoire réservée… les valeurs possibles sont différentes suivant qu’on regarde de l’intérieur ou de l’extérieur du processus. Pour compliquer un peu les choses, la mémoire est géré par « pages », et donc ces pages ne sont pas nécessairement pleines des données qui nous concernent.

vraiment pas clair les données de top

La mémoire réservée, un indicateur potable

Potable dans le sens qu’il ne traduit pas nécessairement la valeur réelle à l’instant T de la mémoire consommée, mais la mémoire maximale utilisable théoriquement par un processus. Par exemple, je teste HHVM en ce moment, il annonce 126Mo de réservé, mais entre avant et après sont lancement, je n’ai que grosso modo 50Mo de mangé sur la mémoire totale. Juste avant de le couper, il avait déjà tourné pendant plusieurs jours, et la mémoire totale avoisinait les 300Mo soit environ 70Mo de plus. 50+70 = 120, soit pas loin des 126Mo réservés. Mais ce n’est pas une mesure au doigt mouillé qu’on cherche ici.

ps, l’outil d’information imbuvable mais complet

Pour extraire la valeur de la quantité de mémoire réservée, je me repose sur la valeur retournée par ps. Cette valeur est un pourcentage de la mémoire totale, alors il faudra un peu de travail pour arriver à un résultat potable. J’utilise les switches aux pour être sûr d’avoir tous les processus, car on pourrait avoir besoin de l’info sur un processus qui ne nous appartient pas.

free pour avoir la mémoire totale

free est un utilitaire renseignant sur l’état de la mémoire : quantité totale, quantité utilisée, quantité restante… j’utilise le switch -m pour avoir les valeurs en méga-octets.

grep et awk pour filtrer le tout

On a déjà vu ces outils dans l’article sur les stats Freebox : grep va nous permettre d’isoler la ligne du processus qu’on veut, et awk seulement le pourcentage réservé affiché dans cette ligne.

Le tout dans un script

Plusieurs lignes sont nécessaires, alors on va tout mettre dans un fichier, qu’on appellera, au pif, memoire.sh (très original) :

Une fois n’est pas coutume je fais quelques vérifications d’usage : est-ce qu’on lui passe bien un seul argument, est-ce que le processus existe. Si c’est le cas, je stocke les résultats des recherches de mémoire réservée ainsi que la mémoire totale. Enfin je renvoie le calcul de mémoire réservée. D’ailleurs, j’ai du installer bc pour l’occasion car Bash ne sait pas faire de calcul en virgule flottante.

Après avoir fait ça et en être tout fier, j’ai un peu ragé, parce que j’ai fini par tomber sur un outil bien plus précis que le mien, qui ne fait finalement qu’extraire et recalculer simplement une valeur existante.

smem, l’artillerie (très) lourde

smem est un outil permettant d’afficher quantité d’informations sur la mémoire vive. Je l’ai découvert dans une étable bien connue, et je me suis renseigné en plus sur le site officiel de l’outil. Très complet, je vous invite à lire les infos du site officiel pour en savoir plus, notamment sur la Proportional Set Size, plus représentative finalement de ce que j’utilise, la Resident Set Size.

Je ne l’ai pas testé moi-même pour une bonne raison : s’il est packagé pour Debian, la quantité de dépendances nécessaires est énorme, et surtout lié au fait de pouvoir afficher des graphiques dans les environnements qui le supporte. Quand on voit ça :

On comprend vite pourquoi j’ai annulé. Non pas que l’espace disque soit restreint à ce point, mais j’aime garder un environnement « optimisé », et installer tout ça alors que ça ne sert qu’à un seul outil, en plus sans interface graphique (donc plusieurs paquets sont strictement inutiles), alors je m’en passe. Mais si vous n’avez pas ces critères, foncez, c’est du bon outil.