Qu'est-ce qu'un octet privé, un octet virtuel, un ensemble de travail ?

Question

J'essaie d'utiliser l'utilitaire Windows perfmon pour déboguer les fuites de mémoire dans un processus.

C'est ainsi que perfmon explique ces termes :

Ensemble de travail est la taille actuelle, en octets, de l'ensemble de travail de ce processus. L'ensemble de travail est l'ensemble des pages de mémoire récemment touchées par les threads du processus. Si la mémoire libre de l'ordinateur est supérieure à un seuil, des pages sont laissées dans l'ensemble de travail d'un processus même si elles ne sont pas utilisées. Lorsque la mémoire libre tombe en dessous d'un seuil, les pages sont retirées des ensembles de travail. Si elles sont nécessaires, elles sont alors remises dans l'ensemble de travail avant de quitter la mémoire principale.

Octets virtuels est la taille actuelle, en octets, de l'espace d'adressage virtuel que le processus utilise. L'utilisation de l'espace d'adressage virtuel n'implique pas nécessairement l'utilisation correspondante de pages de disque ou de mémoire principale. L'espace virtuel est fini, et le processus peut limiter sa capacité à charger des bibliothèques.

Octets privés est la taille actuelle, en octets, de la mémoire que ce processus a allouée et qui ne peut être partagée avec d'autres processus.

Voici les questions que je me pose :

Est-ce que ce sont les octets privés que je dois mesurer pour être sûr que le processus a des fuites, car il n'implique pas de bibliothèques partagées et les fuites, si elles se produisent, viendront du processus lui-même ?

Quelle est la mémoire totale consommée par le processus ? S'agit-il des octets virtuels ou de la somme des octets virtuels et du Working Set ?

Y a-t-il une relation entre les octets privés, l'ensemble de travail et les octets virtuels ?

Existe-t-il d'autres outils qui donnent une meilleure idée de l'utilisation de la mémoire ?

Answer 1

La réponse courte à cette question est que aucune de ces valeurs n'est un indicateur fiable de la quantité de mémoire qu'un exécutable utilise réellement, et aucune d'entre elles n'est vraiment appropriée pour déboguer une fuite de mémoire.

Octets privés font référence à la quantité de mémoire dont dispose l'exécutable du processus demandé - pas nécessairement le montant qu'il représente utilisant réellement . Ils sont "privés" car ils excluent (généralement) les fichiers mappés en mémoire (c'est-à-dire les DLL partagées). Mais - voici le problème - ils n'excluent pas nécessairement la mémoire. alloué par ces fichiers . Il n'y a aucun moyen de savoir si un changement dans les octets privés est dû à l'exécutable lui-même, ou à une bibliothèque liée. Les octets privés sont également no exclusivement de la mémoire physique ; ils peuvent être paginés sur le disque ou dans la liste des pages en attente (c'est-à-dire qu'ils ne sont plus utilisés, mais pas encore paginés non plus).

Ensemble de travail se réfère au total physique la mémoire vive (RAM) utilisée par le processus. Cependant, contrairement aux octets privés, cette valeur inclut également les fichiers mappés en mémoire et diverses autres ressources, ce qui en fait une mesure encore moins précise que les octets privés. Il s'agit de la même valeur que celle indiquée dans le "Mem Usage" du Gestionnaire des tâches et qui a été la source d'une confusion sans fin ces dernières années. La mémoire dans l'ensemble de travail est "physique" dans le sens où elle peut être adressée sans défaut de page ; cependant, la liste des pages en attente est la suivante également toujours physiquement dans la mémoire mais ne sont pas signalés dans le Working Set, et c'est pourquoi vous pouvez voir l'utilisation de la mémoire chuter soudainement lorsque vous minimisez une application.

Octets virtuels sont le total espace d'adressage virtuel occupé par l'ensemble du processus. Il s'agit d'un ensemble similaire à l'ensemble de travail, dans le sens où il inclut les fichiers mappés en mémoire (DLL partagées), mais aussi les données de la liste d'attente et les données qui ont déjà été paginées et se trouvent dans un fichier de pagination sur le disque. Le total des octets virtuels utilisés par chaque processus d'un système soumis à une forte charge représentera une quantité de mémoire nettement supérieure à celle dont dispose réellement la machine.

Donc les relations sont :

• Les octets privés correspondent à ce que votre application a réellement alloué, mais incluent l'utilisation des fichiers de pages ;
• L'ensemble de travail est constitué des octets privés non paginés et des fichiers mappés en mémoire ;
• Les octets virtuels sont l'ensemble de travail plus les octets privés paginés et la liste de réserve.

Il y a un autre problème ici ; tout comme les bibliothèques partagées peuvent allouer de la mémoire à l'intérieur de votre module d'application, ce qui peut entraîner de faux positifs signalés dans les octets privés de votre application, su peut également finir par allouer de la mémoire à l'intérieur de l'application partagé modules, ce qui conduit à de faux négatifs . Cela signifie qu'il est possible que votre application ait une fuite de mémoire qui ne se manifeste jamais dans les octets privés. Peu probable, mais possible.

Les octets privés sont un moyen raisonnable approximation de la quantité de mémoire que votre exécutable utilise et peut être utilisé pour aider à réduire une liste de candidats potentiels pour une fuite de mémoire ; si vous voyez que le nombre augmente sans cesse et sans fin, vous voudriez vérifier ce processus pour une fuite. Cela ne peut cependant pas être le cas, prouver qu'il y a ou non une fuite.

L'un des outils les plus efficaces pour détecter/corriger les fuites de mémoire dans Windows est en fait Visual Studio (le lien renvoie à la page sur l'utilisation de VS pour les fuites de mémoire, pas à la page du produit). Rational Purify est une autre possibilité. Microsoft propose également un programme plus général document sur les meilleures pratiques sur ce sujet. D'autres outils sont répertoriés dans cette question précédente .

J'espère que cela clarifie certaines choses ! La recherche de fuites de mémoire est l'une des choses les plus difficiles à faire en matière de débogage. Bonne chance.

Answer 2

La définition des compteurs perfmon a été cassée depuis le début et, pour une raison quelconque, semble être trop difficile à corriger.

Un bon aperçu de la gestion de la mémoire de Windows est disponible dans la vidéo " Les mystères de la gestion de la mémoire dévoilés "sur MSDN : Il couvre plus de sujets que nécessaire pour traquer les fuites de mémoire (par exemple la gestion des ensembles de travail) mais donne suffisamment de détails dans les sujets pertinents.

---

Pour vous donner une idée du problème que posent les descriptions des compteurs de perfmon, voici l'histoire des octets privés de " Compteur de performance des octets privés -- Attention ! " sur MSDN :

Q : Quand un octet privé n'est-il pas un octet privé ?

R : Quand il n'est pas résident.

Le compteur Private Bytes rapporte la charge de commit du processus. C'est à dire, la quantité d'espace qui a été allouée dans le fichier d'échange pour contenir le contenu de la mémoire privée dans le cas où il est échangé. Note : J'évite le mot "réservé" à cause de la confusion possible avec la mémoire virtuelle dans l'état réservé qui n'est pas engagée.

---

De " Planification des performances " sur MSDN :

3.3 Octets privés

3.3.1 Description

La mémoire privée est définie comme la mémoire allouée à un processus qui ne peut être partagée par d'autres processus. Cette mémoire est plus coûteuse que la mémoire partagée lorsque plusieurs processus de ce type s'exécutent sur une machine. La mémoire privée dans les DLL (traditionnelles) non gérées est généralement constituée de statiques C++ et est de l'ordre de 5 % de l'ensemble de travail total de la DLL.

Answer 3

Vous ne devez pas essayer d'utiliser perfmon, le gestionnaire de tâches ou tout autre outil de ce type pour déterminer les fuites de mémoire. Ils sont bons pour identifier des tendances, mais pas beaucoup plus. Les chiffres qu'ils rapportent en termes absolus sont trop vagues et trop agrégés pour être utiles à une tâche spécifique telle que la détection des fuites de mémoire.

Une réponse précédente à cette question a donné une excellente explication de ce que sont les différents types.

Vous demandez la recommandation d'un outil : Je recommande Memory Validator. Capable de surveiller des applications qui font des milliards d'allocations de mémoire.

http://www.softwareverify.com/cpp/memory/index.html

Clause de non-responsabilité : J'ai conçu Memory Validator.

Answer 4

Il y a une discussion intéressante ici : http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/307d658a-f677-40f2-bdef-e6352b0bfe9e/ D'après ce que j'ai compris de ce fil de discussion, la libération de petites allocations n'est pas reflétée dans Private Bytes ou Working Set.

Pour faire court :

si j'appelle

p=malloc(1000);
free(p);

alors les octets privés ne reflètent que l'allocation, et non la désallocation.

si j'appelle

p=malloc(>512k);
free(p);

alors les octets privés reflètent correctement l'allocation et la désallocation.