So ermitteln Sie, für welchen Prozess der Speicher festgelegt wurde

783
Dunken

Mein System ist voll mit dem festgeschriebenen Speicher belegt (von 8 GB RAM + 2 GB Seitendatei werden 85% des Speichers belegt). Die körperliche Nutzung liegt bei etwa 65%.

Wie kann ich feststellen, in welchem ​​Prozess (en) der größte Teil des zugesagten Speichers zugewiesen wird? Ich verstehe, dass Speicher zwischen Prozessen geteilt werden kann. Bisher habe ich VMMap verwendet, um den festgeschriebenen Speicher anzuzeigen. Dies ist jedoch pro Prozess und berücksichtigt keine durch Seitendateien unterstützten Abschnitte .

enter image description here

enter image description here

2
Wollen Sie also wissen, was Ihren gesamten physischen Speicher verbraucht oder was Ihren gesamten virtuellen Speicher (physisch + paged) oder etwas anderes verwendet? BeowulfNode42 vor 6 Jahren 0
Ich möchte wissen, was für die hohe Commit-Gebühr auf meinem System verantwortlich ist (die Menge des virtuellen Speichers, die für alle Prozesse garantiert ist). Dunken vor 6 Jahren 0

3 Antworten auf die Frage

3
Pimp Juice IT

PowerShell-Lösung

1. Holen Sie sich Top-10-Prozesse mit der höchsten Menge an virtuellem Speicher

Get-Process | Sort PagedMemorySize-Desc | Select Name, PagedMemorySize, VirtualMemorySize -First 10

Ausgabebeispiel

Name VirtualMemorySize PagedMemorySize ---- ----------------- --------------- UrBackupClientBackend 685735936 548347904 explorer 1529909248 478908416 Microsoft.Photos 1303465984 433094656 MBAMService 661987328 228876288 MicrosoftEdgeCP 894496768 219799552 MsMpEng 667783168 205774848 MicrosoftEdgeCP 874590208 202584064 mstsc 440627200 185860096 javaw 886177792 185556992 MicrosoftEdgeCP 802746368 146792448

2. Holen Sie sich die Summe aller festgeschriebenen virtuellen Speicher

Get-WmiObject win32_operatingsystem | Select @}

Ausgabebeispiel

commit ------ 4.56205749511719

Unterstützende Ressourcen

@Dunken Run 'Get-Process | Wählen Sie * -First 10`, um alle Eigenschaften anzuzeigen, die Sie explizit erhalten können, oder was auch immer erforderlich ist. Pimp Juice IT vor 6 Jahren 0
Process.VirtualMemorySize ist die Gesamtzahl der definierten Prozesse des Prozesses. Es umfasst zugeordnete und sogar reservierte Vas. Es ist weitaus größer als der Beitrag des Prozesses zur Festschreibung von Gebühren. Jamie Hanrahan vor 6 Jahren 0
@JamieHanrahan Die Antwort wurde aktualisiert, um sie klarer und mit zusätzlicher Erklärung darzustellen. Geben Sie an, dass eine Aufnahme mit der `Process.PrivateMemorySize-Eigenschaft` in den PowerShell-Befehl eingefügt wird, wie erwähnt. Sie können "PeakPagedMemorySize" zur select -Anweisung hinzufügen, um zu sehen, wie groß die virtuelle Speicherzuordnung jedes Prozesses für das Commit ist. Pimp Juice IT vor 6 Jahren 1
Wie von Jamie VirtualMemorySize darauf hingewiesen, scheint hier nicht viel zu helfen (viel zu groß). Paged / PrivateMemorySize64 scheint "Private Bytes" zu sein (oder in der Nähe), ist aber weitaus kleiner als das, was ich in VMMap als "Committed" bekomme ... Committed Total 954 MB Dunken vor 6 Jahren 0
2
harrymc

Der Prozess-Explorer kann diese Informationen pro Prozess anzeigen:

Bild

So rufen Sie den obigen Bildschirm in Process Explorer auf:

  • Klicken Sie auf Menü Ansicht> Unterer Bereich anzeigen
  • Klicken Sie im Menü auf Ansicht> Ansicht unterer Bereich> DLLs
  • Klicken Sie im Menü auf Ansicht> Ungenutzte Ziehpunkte anzeigen
  • Klicken Sie im oberen Bereich auf einen Prozess
  • Klicken Sie mit der rechten Maustaste auf die Kopfzeilen des unteren Bereichs und wählen Sie Spalten auswählen ... aus.
  • Aktivieren Sie auf der Registerkarte "DLL" die Option " Zugeordnete Größe" und " Mappinq-Typ"
  • OK klicken

Prozess-Hacker können diese Informationen auf ähnliche Weise anzeigen, nachdem Sie einen Prozess ausgewählt und auf ihn geklickt haben . Deaktivieren Sie auf der Registerkarte Handles die Option Unbenannte Handles ausblenden .

Vielleicht fehlt mir etwas, aber wenn ich alle Größenangaben zusammenfasse, sollte ich nicht die gleiche Nummer wie in vmmap sehen? Eigentlich ist die Summe viel niedriger als ich erwartet hätte ... Dunken vor 6 Jahren 0
Welche Spalten vergleichen Sie? harrymc vor 6 Jahren 1
In vmmap zum Beispiel zeigt sqlservr.exe eine Gesamtmenge des zugesagten Speichers von 1,6 GB (1,3 Private Data). Wenn ich die Größen in ProcExp zusammenfasse, bekomme ich 230 MB. Dunken vor 6 Jahren 0
Engagierter Speicher ist alles, was unter anderem den Prozesscode enthält, der für sqlservr.exe groß sein muss. harrymc vor 6 Jahren 0
Ja genau. Wie bekomme ich die Summe? SUMME (Größe) und Arbeitssatz hinzufügen? Dunken vor 6 Jahren 0
Leider gibt es hier undokumentierte Bereiche. Diese Zahlen addieren sich nie ... Vielleicht, weil verschiedene Dienstprogramme unterschiedliche API-Aufrufe verwenden, die nicht zu identischen Ergebnissen führen. harrymc vor 6 Jahren 0
Verstanden (und das ist kein Thema), aber was würden Sie als ungefähre Zahl bezeichnen? Dunken vor 6 Jahren 0
Ich würde mehr auf Process Explorer vertrauen, da dieser die Prozesse selbst analysiert und vom weltweit führenden Windows-Guru geschrieben wird. Andere Dienstprogramme verwenden möglicherweise globale API-Aufrufe, die möglicherweise zu umfassend sind. harrymc vor 6 Jahren 0
1
Jamie Hanrahan

In der Prozessliste von Process Explorer wird in der Spalte "Private Bytes" der Beitrag jedes Prozesses zur Festschreibung von Gebühren angezeigt. Es ist nicht notwendig, die untere Ansicht des Fensters zu betrachten.

Stellen Sie sicher, dass Sie Process Explorer als Administrator ausführen.

Der Task-Manager zeigt die gleichen Informationen auf der Registerkarte "Details" in der Spalte "Commit-Größe" an.

Beachten Sie, dass der Task-Manager in der Spalte "Speicher (privater Arbeitssatz)" nicht dasselbe ist, obwohl er das Wort "privat" verwendet. Dies zeigt die Teilmenge der Festschreibungsgebühr für jeden Prozess, die sich gerade im RAM für diesen Prozess befindet.

Pro Windows-Interna sind die Beitragszahler für die Gesamtbearbeitungsgebühr:

  • private festgeschriebene Vas in jedem Prozess
  • Seitendatei-hinterlegter vas (wird nicht im Prozess "private Bytes" angezeigt)
  • Copy-on-Write-Regionen von zugeordneten Vas
  • Nicht ausgelagerter und ausgelagerter Pool
  • Andere Kernel-Space-Zuordnungen, die nicht explizit durch Dateien gesichert werden (z. B. pageable Code in Treibern oder in ntoskrnl.exe zählt nicht, da er durch die entsprechenden ausführbaren Dateien gesichert wird).
  • Kernel-Stapel - Jeder Thread hat einen
  • Seitentabellen
  • Platz für Seitentabellen, die noch nicht tatsächlich zugewiesen wurden, für die jedoch bereits festgeschriebene vas vorhanden sind
  • AWE-Zuweisungen (Address Windowing Extension)

Windows Intern beschreibt detaillierter, was jedes dieser Dinge ist und warum jedes für die systemweite Festschreibungsgebühr gilt. Leider gibt es keine Zähler für die virtuelle Größe vieler dieser Dinge, worum es bei Commit Charge geht. RAMmap zeigt die physischen Größen einiger, aber nicht der virtuellen Größe.

Hmm ... Ich glaube nicht, dass "Private Bytes" (in ProcExp) oder "Commit size" (in TskMgr) den gesamten zugewiesenen, reservierten Speicher anzeigt. Wenn ich in VMMap einchecke, bekomme ich höhere Zahlen. Ich glaube also, dass PrivateBytes / CommitSize nur einen Teil der Gesamtsumme darstellt ... Dunken vor 6 Jahren 0
Sie sind korrekt. "Private Bytes" (in ProcExp) oder "Commit size" (in TskMgr) enthält keinen reservierten virtuellen Adressraum. _Reserved_vas ist jedoch kein _committed_ memory und zählt nicht zur Festschreibungsgebühr. Sie haben gefragt, wie Sie herausfinden können, welche Prozesse zum festgeschriebenen Speicher beigetragen haben. Die von mir genannten Zähler (eigentlich derselbe Zähler, der mit unterschiedlichen Namen angezeigt wird) geben Sie dem vor. (Sie enthalten Abschnitte, die mit Seitendateien gesichert sind.) VMmap enthält reservierte vas und auch vas, die anderen Dateien als der Auslagerungsdatei zugeordnet sind. Sie tragen nicht dazu bei, Gebühren zu erheben, so dass Sie sich keine Sorgen um sie machen müssen. Jamie Hanrahan vor 6 Jahren 0
Es tut mir leid, ich suche nach festem Speicher: Wenn ich Sie richtig verstehe, sagen Sie, dass Summe (Private Bytes) gleich dem gesamten Speicher ist. Wenn ich das aber auf meinem System mache, beträgt "System Commit" (in ProcExp) 15,4 GB, aber die Summe (Private Bytes) 11,5 GB. Vermisse ich etwas Dunken vor 6 Jahren 0
Nein, ich sage, dass die privaten Bytes jedes Prozesses seinen Beitrag zur gesamten Commit-Gebühr darstellen (= "System Commit"). Es gibt aber noch andere Beiträge zu letzterer Summe. Der nicht ausgelagerte Pool sowie die virtuelle Größe des ausgelagerten Pools sind normalerweise die größten Beitragszahler, die "systemweit" arbeiten. AWE-Zuordnungen sind eine andere (weil sie physischen Speicher aus dem "Umlauf" nehmen), aber diese sind normalerweise selten. Vielleicht könntest du ein paar Screenshots posten? Jamie Hanrahan vor 6 Jahren 0
Klar, Screenshot hinzugefügt. Der nicht ausgelagerte Pool und die virtuelle Größe des ausgelagerten Pools scheinen eher gering zu sein ... Dunken vor 6 Jahren 0
Fügen Sie aus RAMmap (sysinternals) auch die Registerkarte "Usecounts" hinzu. Jamie Hanrahan vor 6 Jahren 1
... wurden Ihre RAMmap- und ProcExp- "Systeminformation" -Schnappens gleichzeitig aufgenommen? Jamie Hanrahan vor 6 Jahren 0
Fast, wie Sie sehen, stimmt "Physischer Gesamtspeicher" überein. Dunken vor 6 Jahren 0
Das ist die Menge an RAM, die Windows zur Verfügung steht. Es ändert sich nur selten, wenn Sie RAM hinzufügen oder entfernen. Jamie Hanrahan vor 6 Jahren 0
Ja, ich weiß. Ich wollte nur darauf hinweisen, dass ich beide Schnappschüsse gleichzeitig gemacht habe ... Dunken vor 6 Jahren 0
Ich sage nur, dass die Schlussfolgerung "beide wurden gleichzeitig genommen" nicht aus der Beobachtung "Physical Total Memory passt" folgt. Wie auch immer ... ja, Sie haben eine Menge Commit-Gebühr, die nicht abgerechnet werden kann. Mein Verdacht ist, dass es sich um Code handelt, der in zugeordneten Dateien enthalten ist und als Copy-on-Write abgebildet wird. Jamie Hanrahan vor 6 Jahren 0
Uuh ... dumm mich ..! OK danke. Ich versuche es weiter zu untersuchen ... Dunken vor 6 Jahren 0

Verwandte Probleme