Die schnelle Antwort: Geben Sie dieser Routine weniger Arbeit. Was meiner Meinung nach bedeutet, dass entweder weniger virtueller Adressraum auf einmal verwendet wird oder mehr RAM hinzugefügt wird.
Details: Erstens, die Routine Sie sehen, MiWalkPageTablesRecursively
hat wenig mit der Auslagerungsdatei direkt zu tun, sondern eher mit Seitentabellen . Seitentabellen sind In-Memory-Strukturen (und sind unabhängig von der Auslagerungsdatei-Konfiguration in allen Windows-Systemen vorhanden). Jeder Prozess verfügt über eine Reihe von Seitentabellen, und es gibt auch einen Satz für den Adressraum des Betriebssystems ("Kernel Space").
Seitentabellen bestehen aus Seitentabelleneinträgen. Für jede Seite (4 KB) des definierten virtuellen Adressraums des Prozesses gibt es einen PTE. Mit "definiert" meine ich, dass es den zugeordneten und den privaten festgeschriebenen Adressraum des Prozesses und gegebenenfalls AWE-Regionen enthält. Es enthält keinen reservierten oder freien Adressraum - Regionen, in denen eine Zugriffsverletzung ausgelöst würde, wenn Sie versuchen, sie zu lesen oder zu schreiben.
(Übrigens: Sie haben nicht nur noch Seitentabellen, auch wenn Sie keine Auslagerungsdatei haben. Sie haben auch weiterhin Paging- und Seitenfehler auf und von der Festplatte, auch wenn Sie keine Auslagerungsdatei haben.)
Das Problem ist wahrscheinlich nicht inhärent MiWalkPageTablesRecursively
. Schließlich ist diese Funktion (oder ein Äquivalent unter einem anderen Namen) seit Windows NT 3.1 Bestandteil von Windows. Es ist in der Tatsache, dass es viel Arbeit tun muss. Dies bedeutet wahrscheinlich, dass es häufig aufgerufen wird.
Ein Hinweis darauf, warum dies der Fall ist, ist in den Routinen zu sehen, die sich früher auf dem Stapel befinden. (Das heißt, näher an der Spitze des WPA-Displays.) Es sieht so aus, als ob der Anrufer MiWalkPageTablesRecursively
in diesem Szenario ist MiWalkPageTables
, das seinerseits von angerufen wird MiAgeWorkingSet
, das wiederum von angerufen wird MiTrimOrAgeWorkingSet
, welches wiederum von MiProcessWorkingSets
, welches angerufen wird wiederum wird gerufen von ... das ist so weit, wie wir gehen müssen.
Jeder Prozess in einem Windows-System hat eine Struktur, die als "Arbeitssatzliste" bezeichnet wird. Dies ist eine Liste aller physischen Seitennummern, die aufgrund von Seitenfehlern des Prozesses im RAM fehlerhaft waren. Der Thread (der "Balance Set Manager" -Thread) wird einmal pro Sekunde aktiviert, um die Arbeitssätze jedes Prozesses zu bereinigen und zu warten. So MiProcessWorkingSets
durchläuft die Prozesse, mit jedem Verfahren zu tun Arbeits wiederum gesetzt.
MiProcessWorkingSets
Aufrufe für jeden Prozess im System MiTrimOrAgeWorkingSet
. Dieser Routinenname bezieht sich auf das "Trimmen" eines Arbeitssatzes (d. H. Das Erkennen von lange nicht verwendeten Seiten und das Entfernen dieser Seiten aus dem Prozess, um im RAM Platz für andere Dinge zu schaffen), oder "Altern" des Arbeitssatzes, was das "Alter" erhöht. Zähler für jeden Arbeitssatzlisteneintrag, auf den seit dem letzten Scannen noch nicht zugegriffen wurde, oder Nullen des Zählers, falls vorhanden. (Der Name bezieht sich auf die "Altern" -Aufgabe, die in der Buchhaltung normalerweise jeden Monat oder jeden Tag ausgeführt wird.) Der Zähler "Alter" wird dann von der Funktion "Trimmen" verwendet, um die am häufigsten nicht verwendeten Seiten zu identifizieren.
Aus der Tatsache, dass dies MiTrimOrAgeWorkingSet
endet MiWalkPageTablesRecursively
, können wir daraus schließen, dass sie den von den Seitentabellen definierten virtuellen Adressraum nach den Seiten durchsuchen, die sich im Arbeitssatz befinden. Bedenken Sie Folgendes: Die für MiTrimOrAgeWorkingSet
die Verarbeitung jedes Prozesses benötigte Zeit ist in etwa proportional zur Größe des virtuellen Adressraums des Prozesses. Die Gesamtzeit, die für jeden Durchlauf benötigt MiProcessWorkingSets
wird, ist in etwa proportional zur Anzahl der Prozesse.
Entweder handelt es sich hier um eine sehr große Anzahl von Seiten in einem Arbeitssatz eines Prozesses oder es muss sich um viele Prozesse handeln.
Und ... warum sollte es so beschäftigt sein? Arbeitspakete werden erst nach dem Älterwerden "getrimmt", und der Betrag, um den die Arbeitspakete "gekürzt" werden, hängt vom RAM-Druck ab - das heißt, wie wenig Arbeitsspeicher Sie haben.
Hat Ihr System zu wenig RAM? Bitte posten Sie Snaps auf der Registerkarte Leistung des Task-Managers Speicherseite plus Detailseite, sortiert nach der Spalte "Arbeitssatz"; plus Registerkarte "Speicher" des Ressourcenmonitors, sortiert nach der Spalte "Harte Fehler"; und RAMmap 'Use Counts' Seite.
Bitte posten Sie mehr von Ihrem WPA-Trace, um mehr "Tiefe" der Anrufe anzuzeigen. Oder stellen Sie die .etl-Datei irgendwo in einem Freigabedienst bereit und verknüpfen Sie sie hier. (Zip es zuerst - sie komprimieren wirklich gut.)
Nebenbei: Warum Routinenamen nicht zwischen WPA und Process Explorer passen
Die eigentliche Frage für die Routinennamen wäre "warum in Process Explorer angezeigte Routennamen einfach falsch sind." In Ihrem Fall gibt es zwei Gründe, die Sie beheben müssen.
Das erste Problem ist, dass anscheinend keine Symbole für Process Explorer richtig konfiguriert sind. Die Konfiguration für Windows Performance Analyzer reicht nicht aus.
Ein sicheres Zeichen, dass Sie dieses Recht nicht haben, ist, dass alle oder fast alle Threads im Prozess "System" mit einem Modulnamen (some.sys oder something.exe, normalerweise ntoskrnl.exe) gefolgt von einem Offset angezeigt werden, wie +0x245
- wie in Ihrer Bildschirmkappe. Es ist in Ordnung, einige davon zu sehen, aber Sie sollten eine ganze Reihe von Ntoskrnl sehen! routinenname gefolgt von keinem offset.
Um dieses Problem zu beheben, besuchen Sie diese Seite im Feldhandbuch zur Windows-Leistungsanalyse . Sie müssen den Symbolsuchpfad für Process Explorer festlegen. Sie können denselben Symboldateipfad verwenden, den Sie für WPA eingerichtet haben, und Sie müssen ProcExp auf eine DLL zeigen, die mit den Windows-Debugging-Tools geliefert wird. Sie müssen also die Debugging-Tools installiert haben - nicht, dass Sie den Debugger direkt verwenden, aber Process Explorer benötigt diese DLL.
Der zweite Grund für die Diskrepanz besteht darin, dass selbst wenn Sie die Symboldateien korrekt für Process Explorer festgelegt haben, die angezeigten Routinenamen nicht häufig mit den Namen einer von Performance Analyzer identifizierten Routine auf innerer Ebene übereinstimmen. Sie sollten jedoch eine Entsprechung auf einem Routinennamen am Anfang des Stapels finden (oben in der Routine-Aufrufstruktur angezeigt, wie in WPA gezeigt).
Zum Beispiel - in Ihrem Fall ist die erste Routine von Interesse KeBalanceSetManager
. (Die beiden vorherigen davor sind für jeden Thread im Systemprozess gleich, aber KeBalanceSetManager
die Routine ist die "oberste" Routine für diesen Thread.) Wenn Sie die Symbole richtig konfiguriert haben, sollte der Process Explorer einen Thread mit dem als "Startadresse", wie hier gezeigt:
Der Prozess-Explorer kann Sie nicht anzeigen, MiWalkPageTablesRecursively
da es sich um etwa sechs Aufrufe des Stapels von der als Thread-Startadresse aufgezeichneten Task handelt, und es ist nicht einmal die innerste Routine (dh sie steht nicht ganz oben im Stack). Solche Informationen (auch wenn sie leicht verfügbar sind, was sie nicht sind) würden sich viel zu schnell ändern, um in einer Process Explorer-Anzeige nützlich zu sein, und versuchen es daher nicht.
Hinweis: Auch bei korrekten Symbolen ist es nicht ungewöhnlich, einige Threads im Systemprozess zu finden, die beispielsweise "Startadresse" zeigen GemCCID.sys+0xd138
, wie Sie in meinem Beispiel sehen werden. Bei dem fraglichen Modul (GemCCID.sys) handelt es sich offensichtlich nicht um eines, für das Microsoft Symboldateien bereitstellt, daher muss Process Explorer nur sagen "Die Thread-Startadresse befindet sich um 0xd138 Bytes vom Anfang des Codes in dieser Datei, und das ist alles, was ich davon wissen."
Hoffe das hilft! Bitte lassen Sie mich wissen, wenn Sie weitere Fragen haben.