Suivi de la mémoire utilisée activement dans les programmes Linux

Je voudrais suivre combien de mémoire différents programmes touchent dans des états spécifiques. Par exemple, disons que j’ai un programme graphique. Il peut consumr beaucoup moins de mémoire lorsqu’il est réduit, car il ne redessine pas la fenêtre, ce qui nécessite la lecture des images et des fonts et l’exécution d’un grand nombre de fonctions de bibliothèque. Ces objects sont toujours accessibles en mémoire, mais ils ne sont pas réellement utilisés.

Les outils tels que top ont une utilité limitée, car ils indiquent simplement la quantité de mémoire mappée dans l’espace d’adressage d’un programme et la quantité de mémoire résidant dans la RAM physique. De même, les détecteurs de fuites ne diront que lorsque la mémoire est inaccessible, pas si elle n’est pas utilisée.

Existe-t-il un outil existant capable de suivre de cette manière la mémoire activement utilisée / inutilisée? Si possible, je voudrais suivre l’utilisation non seulement sur le tas, mais aussi dans la mémoire stockant le code du programme / bibliothèque.

EDIT: Je voudrais clarifier: je veux savoir beaucoup de mémoire, un programme lit, écrit ou exécute réellement après un certain point, c.-à-d. Une fois qu’il atteint un certain état. Bien que le nombre de pages dans l’espace d’adressage et le nombre de pages résidentes soient des mesures importantes, ce n’est pas ce que je recherche.

Je poursuis trois approches en ce moment:

J’ai écrit une bibliothèque qui efface les bits de protection de toutes les régions de mémoire (à l’exception de la stack et de son propre code) lue depuis / proc / self / maps à l’aide de `mprotect`. Il dispose d’un gestionnaire de segfault qui restaure les bits de protection et incrémente un compteur. Je le charge avec `LD_PRELOAD` et il commence à suivre l’access à la mémoire à la réception d’un signal. Cela a produit de véritables fautes avec des adresses apparemment fausses (elles ne sont stockées dans aucun registre ni aucune mémoire au moment de la panne).
J’ai écrit un programme `purge` qui alloue et lit de la mémoire en utilisant` mmap` jusqu’à ce que `mmap` renvoie une erreur. Il est à espérer que cela expulse toutes les pages du processus cible, ce qui est suspendu pendant que «purge» est en cours d’exécution. Je compte ensuite le nombre de pages-in lorsque le processus cible est repris, en utilisant `pidstat`. Cela semble fonctionner mais c’est un instrument très brutal. Il ne donne aucune information sur les pages touchées.
On m’a dit que valgrind vous permet d’écrire des plug-ins qui entraînent l’exécution de certaines actions sur certains événements, par exemple des access mémoire. Cela semble prometteur jusqu’ici.

Cela peut être dérivé des données dans / proc / pid / smaps. Cela décompose une valeur RSS pour chaque zone mappée (y compris la stack, le texte / les données et les régions mappées de manière anonyme), afin que vous puissiez voir exactement ce qui est résident pour chaque object chargé, ainsi que la stack et le segment de mémoire.

Quelques liens utiles:

L’outil de mise en cache de l’outil Valgrind effectue un bon travail de suivi de l’utilisation de la mémoire.

Il y a aussi quelques outils qui montrent la sortie de cachegrind graphiquement.

Modifier pour répondre aux informations mises à jour:
Avant l’émergence de valgrind, j’ai utilisé un projet appelé mpatrol.
Il utilise mprotect () pour rendre les pages en lecture seule et pour suivre l’access aux pages.
pages. Il permet également de spécifier quand commencer et arrêter le reporting,
comme après le nième malloc, entre autres spécifications.

Il peut faire beaucoup, ou toutes les fonctionnalités que vous recherchez.

Une mise en garde, il est beaucoup plus lent que le valgrind.