Je sais que l'ensemble de travail est la quantité réelle de mémoire que le processus utilise et que les octets privés sont la quantité mise de côté au cas où il en aurait besoin.
Dois-je donc additionner les deux pour savoir combien de mémoire est réellement enlevée aux autres processus du système ?
Je crains que ce ne soit pas aussi simple. En particulier, les octets privés ne sont pas très utiles pour répondre à la question que vous posez.
La première chose à garder à l'esprit est qu'une page mémoire peut exister dans la mémoire principale ou dans un stockage externe (aujourd'hui "pagination disque" ou "swap"). La deuxième est qu'un processus aura des pages de mémoire privées dans son empreinte, mais utilisera également des objets dans des pages partagées, que d'autres processus utilisent en même temps.
Ensemble de travail est la taille des pages appartenant au processus, qui sont actuellement stockées dans la mémoire principale. Lorsqu'une page de mémoire utilisée par un processus est déplacée vers le fichier de pages, elle est retirée de la métrique de l'ensemble de travail, et lorsqu'elle est rappelée en mémoire principale, elle y est ajoutée à nouveau.
L'ensemble de travail ne se réfère cependant pas exclusivement à la mémoire que votre processus possède. les processus utilisent de nombreux objets de mémoire partagée, et la taille de ces objets est reflétée dans le stat. malheureusement, lorsque deux processus partagent un objet de 1MB, leurs deux processus montrent une allocation de 1MB dans l'ensemble de travail, donc si vous additionnez tous les ensembles de travail, l'objet de 1MB serait enregistré deux fois, donc l'accumulation de toutes les tailles de vos ensembles de travail pourrait dans des cas extrêmes, sembler dépasser la taille de la ram disponible. voir plus ici : http://cybernetnews.com/cybernotes-Windows-memory-usage-explained/
Octets privés se réfère à la quantité d'espace de fichier de page qui est allouée au processus (pas nécessairement utilisé) dans le cas où l'empreinte mémoire privée du processus est complètement paginée vers le swap. La plupart du temps, le processus n'est pas entièrement (ou du tout) résident du fichier de page, c'est pourquoi les octets privés semblent avoir de la "place" pour une allocation supplémentaire. Ce n'est cependant pas le cas.
Cependant, les octets privés ne font référence qu'à la mémoire privée du processus, donc cette valeur peut ne pas refléter les ressources partagées (même si la ressource partagée n'est utilisée que par ce processus pour le moment).
"Working set Private" ("WS Private bytes" ou "Private WS" dans l'explorateur de processus en fonction de la version) est probablement la meilleure mesure pour votre utilisation. elle ne se préoccupe pas du fichier de pages, vous obtenez donc une représentation précise de l'impact des processus sur votre ram physique, et elle ne compte pas deux fois les objets partagés. les objets partagés ne sont comptabilisés qu'une seule fois (uniquement pour le processus qui les a créés), mais cela signifie également que dans une perspective de processus unique, vous n'enregistrez pas le fait que votre processus utilise des objets partagés créés par un autre processus, de sorte que votre processus pourrait utiliser plus de ram sur une autre machine ou dans une situation où il était nécessaire de créer l'objet partagé lui-même au lieu d'utiliser l'instance d'un autre processus. Le gestionnaire de tâches de Windows utilise l'ensemble de travail privé comme mesure de l'utilisation de la mémoire.
J'espère que cela vous aidera
Réponse tangentielle ici.
Si vous n'avez pas besoin d'utiliser Process Explorer, le moyen le plus rapide est d'exécuter ce snippet dans PowerShellCore :
Get-Process -Name $processName | Select-Object PM,WS | Format-Table @{Label='PM (MB)';Expression={$_.PM / 1MB}},@{Label='WS (MB)';Expression={$_.WS / 1MB}}SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
