2016-07-04 3 views
2

Existe-t-il un compteur de performance qui indique quelle quantité de mémoire d'un processus spécifique est renvoyée? J'ai un serveur qui a 40 Go de RAM disponible (de 128 Go de mémoire physique) mais la quantité de données paginée est de plus de 100 Go. Comment puis-je savoir lequel de mes processus est responsable de cette énorme consommation de fichiers de pages?Quelle quantité de mémoire d'un processus est renvoyée?

Il serait également acceptable d'avoir un traçage xperf pour voir quand l'activité de sortie de page se produit. Mais en dehors de nombreuses écritures dans le fichier de la page, je ne peux pas voir à partir de quels processus la mémoire est écrite dans le fichier de la page. Référence Set Tracing ne me montre que dans la mesure où je comprends la consommation de mémoire physique de mon processus. Mais il ne semble pas suivre l'activité de la page.

Mise à jour Le système d'exploitation est Windows Server 2012 R2

+1

Je suis sûr que c'est un accident, mais vous avez oublié de mentionner le système d'exploitation. Pas que je connaisse cette réponse à travers :) – Makketronix

Répondre

1

Le fournisseur ETW "Microsoft-Windows-Kernel-Memory" a un mot-clé "KERNEL_MEM_KEYWORD_WS_SWAP" ("0x80"). Ici, il y a des événements qui se produisent lorsque les données sont paginées/paginée:

 <event value="4" symbol="WorkingSetOutSwapStart" version="0" task="WorkingSetOutSwap" opcode="win:Start" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStartArgs"/> 
    <event value="4" symbol="WorkingSetOutSwapStart_V1" version="1" task="WorkingSetOutSwap" opcode="win:Start" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStartArgs_V1"/> 
    <event value="5" symbol="WorkingSetOutSwapStop" version="0" task="WorkingSetOutSwap" opcode="win:Stop" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStopArgs"/> 
    <event value="5" symbol="WorkingSetOutSwapStop_V1" version="1" task="WorkingSetOutSwap" opcode="win:Stop" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStopArgs_V1"/> 
    <event value="6" symbol="WorkingSetInSwapStart" version="0" task="WorkingSetInSwap" opcode="win:Start" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStartArgs"/> 
    <event value="6" symbol="WorkingSetInSwapStart_V1" version="1" task="WorkingSetInSwap" opcode="win:Start" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetOutSwapStartArgs_V1"/> 
    <event value="7" symbol="WorkingSetInSwapStop" version="0" task="WorkingSetInSwap" opcode="win:Stop" level="win:Informational" keywords="KERNEL_MEM_KEYWORD_WS_SWAP" template="WorkingSetInSwapStopArgs"/> 

Ici, vous obtenez des données comme le nombre de pages consultées (PagesProcessed):

<template tid="WorkingSetOutSwapStartArgs"> 
    <data name="ProcessId" inType="win:UInt32"/> 
</template> 
<template tid="WorkingSetOutSwapStopArgs"> 
    <data name="ProcessId" inType="win:UInt32"/> 
    <data name="Status" inType="win:HexInt32"/> 
    <data name="PagesProcessed" inType="win:UInt32"/> 
</template> 
<template tid="WorkingSetInSwapStopArgs"> 
    <data name="ProcessId" inType="win:UInt32"/> 
    <data name="Status" inType="win:HexInt32"/> 
</template> 
<template tid="WorkingSetOutSwapStartArgs_V1"> 
    <data name="ProcessId" inType="win:UInt32"/> 
    <data name="Flags" inType="win:HexInt32"/> 
</template> 
<template tid="WorkingSetOutSwapStopArgs_V1"> 
    <data name="ProcessId" inType="win:UInt32"/> 
    <data name="Status" inType="win:HexInt32"/> 
    <data name="PagesProcessed" inType="win:Pointer"/> 
    <data name="WriteCombinePagesProcessed" inType="win:Pointer"/> 
    <data name="UncachedPagesProcessed" inType="win:Pointer"/> 
    <data name="CleanPagesProcessed" inType="win:Pointer"/> 
</template> 

Jouer avec elle si elle inclut toutes les données dont vous avez besoin.

+0

Ce fournisseur a l'air sympa mais l'événement d'échange n'est déclenché que si quelqu'un force via un appel api à échanger l'ensemble de travail du processus. Les activités normales d'ajustement de l'ensemble de travail ne sont pas consignées par ce fournisseur.Pourtant, c'est un bon indice pour suivre au moins les swap outs explicites déclenchés par l'application elle-même. –

0

Dans Xperf vous voulez chercher Hard Faults - noter que ceci est un type de Page Fault, mais les défauts de page peuvent souvent être traitées dans le logiciel sans toucher le lecteur . Vous pouvez ajouter une colonne dans le Gestionnaire des tâches pour afficher les erreurs de page pour chaque processus.

Vous pouvez obtenir des informations sur un processus en utilisant un outil comme https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx qui vous indiquera pour chaque bloc de mémoire dans l'espace d'adressage du processus quel type il est et combien est validé. Cependant, c'est la mémoire engagée qui peut être paginée, et VirtualQueryEx() ne vous dit pas à ce sujet.

Il est également important de noter qu'une grande quantité de mémoire paginée n'est pas toujours une mauvaise chose - ce sont les fautes dures qui sont lentes. Edit: Hmm, si vous voulez un test unique intrusif, je suppose qu'il ya l'option hacky de combiner VirtualQueryEx() et ReadProcessMemory() pour toucher chaque page validée dans un processus afin de pouvoir compter les fautes dures!

+0

Je connais les fautes de page. C'est pour paginer en mémoire à partir du fichier de la page. Mais je veux savoir ce qui est paginé dans le fichier de la page à partir des processus et quand. Peut-être quelqu'un supprime-t-il explicitement l'ensemble de travail et se demande plus tard pourquoi son processus a des temps de réponse si élevés ... –

+0

Je suis d'accord, c'est une information cruciale. Je voudrais voir cela dans le gestionnaire de tâches, comme une indication de combien de pression de mémoire mon système * était * sous par le passé. La meilleure approximation que je peux offrir est de comparer la taille de travail à la taille de commit, mais cela est imparfait puisque la différence peut provenir de pages qui n'ont pas encore été touchées ou paginées vers des fichiers d'images . La mémoire recherchée sera * éventuellement * une mauvaise chose. –