API .NET pour déterminer la fragmentation VM

Question

Y at-il une API .NET pour obtenir des informations détaillées sur l'utilisation VM? Je suis particulièrement intéressé pour déterminer le niveau de fragmentation mon espace d'adressage est.

Merci!

Answer 1

Le genre de fonctions API de Windows qui peut vous donner un aperçu de ce sont VirtualQueryEx () pour énumérer les sections de mémoire virtuelle et découvrir l'espace inutilisé, GetProcessHeaps () pour trouver ce tas sont créés à l'intérieur du processus et HEAPWALK () découvrir comment les blocs dans chaque tas sont utilisés.

Ce ne va pas être facile, en particulier HEAPWALK () est une fonction gênante dans un programme en cours d'exécution. Vous devriez jeter un oeil à la Sysinternals VMMap utilitaire , il fournit d'excellents diagnostics de mémoire virtuelle.

La chute avec ceci est que cela n'a pas vraiment vous aider à résoudre un problème de fragmentation de la mémoire. Il n'y a rien que vous pouvez faire pour influer sur la façon dont le gestionnaire de mémoire de Windows sous-alloue l'espace de mémoire virtuelle. Court de ne pas allouer de la mémoire. Si vous luttez maintenant avec OOM, vous devriez vraiment envisager de re-architecturer votre application. Ou le passage à un système d'exploitation 64 bits, la solution de deux cents dollar.

Answer 2

Réponse courte: non. Vous devez taper dans l'API Win32 pour cela. Je ne sais vraiment pas ce que l'API appel que vous utilisez bien ...

Une recherche rapide sur http://www.pinvoke.net m'a conduit à ceci:

[DllImport("coredll.dll", SetLastError=true)]
static extern void GlobalMemoryStatus(ref MEMORYSTATUS lpBuffer);

Mais le struct MEMORYSTATUS ne semble pas avoir toutes les informations dont vous avez besoin (juste utilisation et d'autres informations de la mémoire physique et virtuelle).

Vous devez creuser pour trouver autour de la méthode MSDN nécessaire.

Answer 3

Un tel appel n'a pas de sens dans le monde géré, étant donné que différents hôtes CLR peuvent gérer différentes choses (comme l'hôte de l'application normale ou SQL Server). Et ne pas oublier que le GC peut faire bouger les choses autour, de sorte que la fragmentation n'est pas vraiment un problème est le GC compacter le tas.

Cependant, cela me amène au point suivant, vous devriez être en mesure d'obtenir ces informations en accueillant le CLR vous. Vous voudrez peut-être regarder ce blog sur ce sujet .

Answer 4

Il faut vraiment descendre dans l'API Win32 / Win64 pour obtenir ces informations au niveau de la page. Plus détaillée et vous avez besoin de connaître le fonctionnement interne de ne importe quel tas que vous regardez, que ce soit un tas de C, tas Win32, un tas de petit objet CLR ou un tas grand objet CLR.

Cependant, vous pouvez utiliser mémoire virtuelle Validator (ce qui est commercial, mais gratuit) pour visualiser l'espace de mémoire virtuelle, et examiner aussi la page de l'espace mémoire en page, et paragraphe par paragraphe. Regardez les visuels d'abord comme qui le rend facile de voir les problèmes généraux et les tendances. Venez lire les informations détaillées sur les pages et les paragraphes lorsque vous avez décidé ce que les zones mémoire sont problématiques.

Voici un article de blog décrivant ce que sont.

Answer 5

En C, vous pouvez écrire quelque chose comme ça pour savoir la quantité de mémoire allouée:

HANDLE heap = GetProcessHeap();
PROCESS_HEAP_ENTRY entry;
memset(&entry, 0, sizeof(entry));
unsigned long size = 0;
while(HeapWalk(heap, &entry)) {
    if(entry.wFlags & PROCESS_HEAP_ENTRY_BUSY) {
        size += entry.cbData;
    }
}

Les GetProcessHeaps () peuvent être nécessaires si d'autres segments sont utilisés dans ce cas, vous avez besoin d'une seconde boucle pour parcourir tous les tas. Je ne sais pas pourquoi leur serait plus d'un bien.

Dans votre cas, vous devriez probablement compter le nombre de blocs et leurs tailles. Si vous souhaitez enregistrer ce disque, je vous suggère d'abord compter le nombre de blocs, allouer un tampon pour enregistrer toutes les informations, puis enregistrez le tampon dans un fichier pour un examen ultérieur.