Sur OSX le moniteur d'activité vous donne réellement une très bonne estimation. La mémoire privée est pour la mémoire sûre qui est seulement utilisée par votre application. Par exemple. La pile de mémoire et toute la mémoire réservée dynamiquement en utilisant malloc() et les fonctions/méthodes comparables (alloc méthode pour Objective-C) est de la mémoire privée. Si vous utilisez un fork, la mémoire privée sera partagée avec votre enfant, mais marquée copy-on-write. Cela signifie que tant qu'une page n'est modifiée par aucun processus (parent ou enfant), elle est partagée entre eux. Dès que l'un des processus modifie une page, cette page est copiée avant d'être modifiée. Même si cette mémoire est partagée avec les enfants fork (et elle ne peut être partagée qu'avec des fork fork), elle est toujours montrée comme mémoire "privée", car dans le pire des cas, chaque page sera modifiée (tôt ou tard)) puis de nouveau privé à chaque processus.La mémoire partagée est la mémoire actuellement partagée (les mêmes pages sont visibles dans l'espace de processus virtuel de différents processus) ou qui est susceptible de devenir partagée à l'avenir (par exemple, la mémoire en lecture seule, car il n'y a aucune raison pour ne pas partager la mémoire en lecture seule). Au moins, c'est ainsi que j'ai lu le code source de certains outils de ligne de commande d'Apple. Donc, si vous partagez de la mémoire entre des processus utilisant mmap (ou un appel comparable qui mappe la même mémoire en plusieurs processus), ce sera de la mémoire partagée. Cependant, le code exécutable lui-même est également de la mémoire partagée, car si une autre instance de votre application est démarrée, il n'y a aucune raison qu'elle ne partage pas le code déjà chargé en mémoire (les pages de code exécutables sont en lecture seule par défaut). application dans un débogueur). Ainsi, la mémoire partagée est vraiment la mémoire utilisée par votre application, comme celle privée, mais elle peut également être partagée avec un autre processus (ou non, mais pourquoi ne compterait-elle pas dans votre application si elle était partagée?)
La mémoire réelle est la quantité de RAM actuellement "affectée" à votre processus, qu'elle soit privée ou partagée. Cela peut être exactement la somme de privé et partagé, mais habituellement il ne l'est pas. Votre processus peut avoir plus de mémoire qu'il n'en a actuellement besoin (cela accélère les demandes pour plus de mémoire dans le futur), mais ce n'est pas une perte pour le système. Si un autre processus a besoin de mémoire et qu'aucune mémoire libre n'est disponible, avant que le système ne commence à échanger, il enlèvera cette mémoire supplémentaire de votre processus et lui assignera un autre processus (opération rapide et indolore); par conséquent, votre prochain appel malloc pourrait être un peu plus lent. La mémoire réelle peut également être plus petite que la mémoire privée et physique; En effet, si votre processus demande de la mémoire au système, il ne recevra que de la "mémoire virtuelle". Cette mémoire virtuelle n'est liée à aucune page de mémoire réelle tant que vous ne l'utilisez pas (donc 10 Mo de mémoire, n'utilisez qu'un octet, votre processus n'obtiendra qu'une seule page, 4096 octets, de mémoire assignée - le reste n'est attribué que si vous en avez réellement besoin). La mémoire supplémentaire qui est permutée ne peut pas non plus compter pour la mémoire réelle (pas sûr de cela), mais elle comptera pour la mémoire partagée et privée.
La mémoire virtuelle est la somme de tous les blocs d'adresses considérés comme valides dans l'espace de traitement des applications. Ces adresses peuvent être liées à la mémoire physique (à nouveau privée ou partagée), ou elles peuvent ne pas l'être, mais dans ce cas, elles seront liées à la mémoire physique dès que vous utiliserez l'adresse. L'accès aux adresses mémoire en dehors des adresses connues provoquera un SIGBUS et votre application va planter. Lorsque la mémoire est permuté, l'espace d'adressage virtuel pour cette mémoire reste valable et l'accès à ces adresses, la mémoire est raffraîchissement dans
Conclusion:.
Si votre application n'utilise pas explicitement ou implicitement la mémoire partagée, la mémoire privée est la quantité de mémoire dont votre application a besoin en raison de la taille de la pile (ou des tailles si elle est multithread) et des appels malloc() que vous avez faits pour la mémoire dynamique. Vous n'avez pas à vous soucier beaucoup de la mémoire partagée ou réelle dans ce cas. Si votre application utilise de la mémoire partagée, y compris une interface graphique, où la mémoire est partagée entre votre application et le WindowServer par exemple, vous pouvez également consulter la mémoire partagée. Un nombre de mémoire partagée très élevé peut signifier que vous avez trop de ressources graphiques chargées en mémoire pour le moment.
La mémoire réelle n'a que peu d'intérêt pour le développement d'applications. Si elle est plus grande que la somme de partagé et privé, cela ne signifie rien d'autre que que le système est paresseux à la mémoire de votre processus. Si elle est plus petite, votre processus a demandé plus de mémoire que nécessaire, ce qui n'est pas mal non plus, puisque tant que vous n'utilisez pas toute la mémoire demandée, vous ne «volez» pas la mémoire du système.Si elle est beaucoup plus petite que la somme de shared et private, vous ne pouvez envisager de demander moins de mémoire que possible, car vous demandez un peu plus de mémoire (encore une fois, ce n'est pas mauvais, mais cela me dit que votre code n'est pas optimisé pour une utilisation minimale de la mémoire et s'il est multi plate-forme, les autres plates-formes peuvent ne pas avoir un traitement de mémoire aussi sophistiqué, donc vous pouvez préférer allouer beaucoup de petits blocs plutôt que quelques gros blocs. sur).
Si vous n'êtes toujours pas satisfait de toutes ces informations, vous pouvez obtenir encore plus d'informations. Ouvrez un terminal et exécutez:
sudo vmmap <pid>
où est l'ID de processus de votre processus. Cela vous montrera les statistiques pour EVERY bloc de mémoire dans votre espace de processus avec l'adresse de début et de fin. Il vous dira également d'où vient cette mémoire (un fichier mappé, une pile de mémoire, une mémoire mallocée, une section __DATA ou __TEXT de votre exécutable?), Sa taille en KB, ses droits d'accès et son caractère privé, partagé ou copier-sur-écrire. S'il est mappé à partir d'un fichier, il vous donnera même le chemin d'accès au fichier.
Si vous ne souhaitez que l'utilisation de la RAM « réelle », utilisez
sudo vmmap -resident <pid>
Maintenant, il affichera pour chaque bloc de mémoire la taille du bloc de mémoire est virtuellement et combien il est vraiment actuellement présent dans la mémoire physique.
À la fin de chaque sauvegarde est également une table de synthèse avec la somme des différents types de mémoire. Cette table ressemble à ceci pour Firefox maintenant sur mon système:
REGION TYPE [ VIRTUAL/RESIDENT]
=========== [ =======/========]
ATS (font support) [ 33.8M/ 2496K]
CG backing stores [ 5588K/ 5460K]
CG image [ 20K/ 20K]
CG raster data [ 576K/ 576K]
CG shared images [ 2572K/ 2404K]
Carbon [ 1516K/ 1516K]
CoreGraphics [ 8K/ 8K]
IOKit [ 256.0M/ 0K]
MALLOC [ 256.9M/ 247.2M]
Memory tag=240 [ 4K/ 4K]
Memory tag=242 [ 12K/ 12K]
Memory tag=243 [ 8K/ 8K]
Memory tag=249 [ 156K/ 76K]
STACK GUARD [ 101.2M/ 9908K]
Stack [ 14.0M/ 248K]
VM_ALLOCATE [ 25.9M/ 25.6M]
__DATA [ 6752K/ 3808K]
__DATA/__OBJC [ 28K/ 28K]
__IMAGE [ 1240K/ 112K]
__IMPORT [ 104K/ 104K]
__LINKEDIT [ 30.7M/ 3184K]
__OBJC [ 1388K/ 1336K]
__OBJC/__DATA [ 72K/ 72K]
__PAGEZERO [ 4K/ 0K]
__TEXT [ 108.6M/ 63.5M]
__UNICODE [ 536K/ 512K]
mapped file [ 118.8M/ 50.8M]
shared memory [ 300K/ 276K]
shared pmap [ 6396K/ 3120K]
Qu'est-ce que cela nous dit? Par exemple. le binaire Firefox et toutes les bibliothèques qu'il charge ont 108 Mo de données ensemble dans leurs sections __TEXT, mais actuellement, seulement 63 Mo de ceux-ci résident actuellement en mémoire. Le support de police (ATS) a besoin de 33 Mo, mais seulement environ 2,5 Mo sont vraiment en mémoire. Il utilise un peu plus de 5 MB de banques de support CG, CG = Core Graphics, ce sont probablement des contenus de fenêtres, des boutons, des images et d'autres données qui sont mises en cache pour un dessin rapide. Il a demandé 256 Mo via des appels malloc et actuellement 247 Mo sont réellement mappés sur des pages mémoire. Il a 14 Mo d'espace réservé pour les piles, mais seulement 248 Ko d'espace de pile est vraiment utilisé en ce moment.
VMMap a aussi un bon résumé ci-dessus la table
ReadOnly portion of Libraries: Total=139.3M resident=66.6M(48%) swapped_out_or_unallocated=72.7M(52%)
Writable regions: Total=595.4M written=201.8M(34%) resident=283.1M(48%) swapped_out=0K(0%) unallocated=312.3M(52%)
Et cela montre un aspect intéressant de l'OS X: Pour mémoire en lecture seule, il ne joue aucun rôle si elle est permutée ou simplement non alloué; il n'y a que résident et non résident. Pour la mémoire inscriptible cela fait une différence (dans mon cas 52% de la mémoire demandée n'a jamais été utilisée et est non alloué, 0% de mémoire a été échangé sur le disque)
Quelle est exactement la « vraie utilisation de la mémoire »? En fonction de votre liste, l'idée de l'utilisation de la mémoire pour un seul processus est inutile ou arbitraire. – BCS
Je définirais «l'utilisation réelle de la mémoire» comme la quantité de mémoire physique (mais pas d'échange) qui serait libérée si je «tais -9» le processus donné. Je crois que ce nombre devrait être quelque part entre les valeurs RSS et PSS rapportées pour un processus. –
@Hongli: Bien que ce soit un vieux fil de discussion, je suis surpris de voir pourquoi le montage de linprocfs ne faisait pas partie de la solution suggérée par quiconque ici, pour FreeBSD. Y a-t-il une raison spécifique pour cela? J'ai de toute façon ajouté cette réponse pour l'amour de l'achèvement. – Arvind