Die Tiefen des Windows-Speichers (Teil 2) — Das Leben einer physischen Seite: fünf Listen und die Wahrheit über die Auslagerungsdatei

Im vorherigen Artikel „Die Tiefen des Windows-Speichers (Teil 1) — Der Augenblick, in dem eine virtuelle Adresse zu physischem RAM wird“ sind wir so weit gefolgt, bis der Seitenfehler-Handler beim ersten Anfassen einer committeten Seite eine physische Seite zuweist. Wohin geht diese physische Seite, nachdem sie aus dem Working Set entfernt wurde?

Oft wird die Erklärung auf „sie wird in die Auslagerungsdatei verdrängt“ verkürzt, aber davor und danach gibt es mehrere Zustände. Eine unveränderte Seite kann mit erhaltenem Inhalt nach Standby wandern. Eine geänderte Seite wartet zuerst auf Modified auf das Zurückschreiben. Bei der Wiederverwendung kann sie Free oder Zeroed durchlaufen, und wenn dieselben Inhalte wieder gebraucht werden, kann sie per Soft Fault aus Standby zurückkehren.

Dieser Artikel nimmt die PFN-Datenbank als Achse und folgt wie eine einzelne physische Seite durch Active, Modified, Standby, Free und Zeroed wandert. Das Lesen der Zahlen selbst setzt den Einführungsartikel „Was bedeutet Windows’ „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen“ voraus.

„Die Tiefen des Windows-Speichers“ — alle 3 Teile

1. Teil 1: Virtuelle Adressen und Seitenfehler
   Wir verfolgen, wann eine committete virtuelle Seite physischen RAM erhält.
2. Teil 2 (dieser Artikel): Das Leben einer physischen Seite
   Wir verfolgen die Zustandsübergänge einer Seite, die das Working Set verlässt, und die Rolle der Auslagerungsdatei.
3. Teil 3: Abschnittsobjekte und Copy-on-Write
   Wir verfolgen den Mechanismus, mit dem DLLs, Dateizuordnungen und gemeinsamer Speicher physische Seiten teilen.

Die Frage, die Teil 2 beantwortet, ist nur eine.

Verschwindet eine physische Seite, die das Working Set verlässt, geht sie auf die Festplatte, oder bleibt sie im RAM?

Zielgruppe sind Entwickler und Betrieb, die vom Mechanismus her verstehen wollen, warum Available hoch ist und Standby ebenfalls, das Verhalten nach Working-Set-Trim, die Auslagerungsdatei-Konfiguration und Speicherkompression. Voraussetzungen sind Windows 10/11 oder aktuelles Windows Server, und erforderlicher Hintergrund sind die Grundlagen von Working Set, Commit sowie Soft-/Hard-Faults. Die Schwierigkeit ist Mittelstufe; wir verwenden interne Begriffe wie PFN und Seitenlisten, konzentrieren uns aber auf das, was sich mit RAMMap und PerfMon ohne Kernel-Debugger beobachten lässt.

1. Zuerst das Fazit

Zunächst die Punkte, die leicht falsch gelesen werden.

• Eine Seite, die das Working Set verlässt, verschwindet nicht unbedingt sofort.
  Eine saubere Seite bleibt auf Standby und kann ohne Plattenlesen zurückkehren, wenn dieselben Inhalte gebraucht werden.
• Eine geänderte Seite kann nicht sofort wiederverwendet werden.
  Private Inhalte werden wiederverwendbar, nachdem sie in die Auslagerungsdatei zurückgeschrieben werden können; eine zugeordnete Datei, nachdem sie in die zugehörige Datei zurückgeschrieben werden können; und so weiter.
• Available enthält Standby.
  Standby ist ein Cache, der noch Inhalte hält, und zugleich ein Wiederverwendungskandidat, der bei Bedarf sofort genommen werden kann.¹
• Das Schreiben in die Auslagerungsdatei ist kein Stapelauftrag, der erst nach vollständiger RAM-Erschöpfung startet.
  Es läuft im Hintergrund gemäß Modified-Liste und Speicherdruck.²³
• Die Auslagerungsdatei ist nicht bloß „langsamer RAM“.
  Sie erweitert das Commit Limit, wird zum Backing Store geänderter privater Seiten und stützt Absturzabbilder.⁴
• Das Deaktivieren der Auslagerungsdatei behebt kein Speicherleck.
  Das Commit Limit sinkt, und Optionen zur wirksamen RAM-Nutzung sowie die Fähigkeit, Abbilder zu erfassen, können verloren gehen.

In einem Satz: bevor Windows eine Seite verwirft, prüft es die Möglichkeit, dass sie wieder gebraucht wird, und ob es einen Ort gibt, von dem die ursprünglichen Inhalte wiederhergestellt werden können.

2. Die PFN-Datenbank — das Hauptbuch auf der physischen-RAM-Seite

Die PTE aus Teil 1 stellte die Übersetzung von einer virtuellen Seite zu einer physischen Seite dar. Das Hauptbuch, das dies von der physischen Seite aus betrachtet und verfolgt, „wofür diese RAM-Seite gerade verwendet wird“, ist die PFN-Datenbank. PFN steht für Page Frame Number: physischer RAM, in Seiteneinheiten nummeriert.

Ein PFN-Eintrag verfolgt begrifflich die folgenden Informationen.

• Den aktuellen Zustand der physischen Seite
• Referenzzähler und Freigabezähler
• Die zugehörige PTE
• Ob sie geändert ist
• Zu welcher Seitenliste sie gehört
• Informationen zu NUMA-Knoten und Priorität

In WinDbg zeigt !pfn Informationen zu einem bestimmten PFN, und !memusage zeigt die physische Speichernutzung und Summen jeder Seitenliste.⁵⁶ Wer dieselbe Welt ohne Kernel-Debugger beobachten will, kann Sysinternals RAMMap nutzen. Use Counts zeigt Zweck und Seitenliste, Priority Summary zeigt Standby nach Priorität, und Physical Pages zeigt die Nutzung pro Seite.⁷

3. Die fünf Zustände in einem Bild verbinden

Dieser Artikel behandelt den Fluss einer physischen Seite vereinfacht als die folgenden fünf Zustände. Genau genommen hat aktuelles Windows Zustände und Listen, die hier nicht gezeichnet sind — Standby nach Priorität, Transition, Bad und andere — und Active meint weniger eine einzelne „Active-Liste“ als den Zustand, über eine gültige PTE aus einem Working Set oder Ähnlichem referenziert zu werden. Trotzdem ist dieses Bild mehr als nützlich, um das Speicherverhalten einer Anwendung zu lesen.

Abbildung 1: Eine im Working Set referenzierte Seite wandert bei sauber nach Standby und bei schmutzig nach Modified. Dieselben Inhalte können zurückkehren; ein anderer Zweck verwendet die Seite direkt wieder oder geht für eine nullerfordernde Zuweisung über Free/Zeroed.

Der wichtigste Punkt in diesem Bild ist, dass das Verlassen des Working Set und das Verlieren der Inhalte nicht dasselbe sind. Außerdem durchläuft eine Standby-Seite, die für einen anderen Zweck genommen wird, nicht unbedingt der Reihe nach Free/Zeroed. Soll sie dem Benutzermodus als neue Demand-Zero-Privatseite übergeben werden, müssen die alten Inhalte gelöscht werden; wird die ganze Seite überschrieben, etwa als Ziel eines Dateilesens, kann die Standby-Identität abgelegt und die Seite direkt wiederverwendet werden.

4. Active / Valid — eine physische Seite, die Sie jetzt referenzieren können

Eine Active/Valid-Seite wird über eine gültige PTE aus dem Working Set eines Prozesses oder aus dem Systemraum referenziert. Die CPU erreicht sie mit gewöhnlicher Adressübersetzung, daher braucht der Zugriff selbst keinen Seitenfehler.

Es gibt jedoch keine Garantie, dass die Seite Active bleibt. Um verfügbaren Speicher zu halten, betrachtet der Speicher-Manager die Working-Set-Größe, wie kürzlich die Seite genutzt wurde, und Ähnliches, und trimmt Kandidatenseiten. Microsofts Working-Set-Dokumentation erklärt ebenfalls, dass der Speicher-Manager Seiten aus dem Working Set entfernt, um verfügbaren Speicher zu schaffen.⁸

4.1. Ein Trim ist keine Freigabe

Was Working-Set-Trimmen vor allem ändert, ist der residente Zustand, sofort über eine gültige PTE referenzierbar zu sein. Unterscheiden Sie die folgenden vier als getrennte Ereignisse.

• Aus dem Working Set entfernen
• Commit freigeben
• Einen virtuellen Adressbereich freigeben
• Die Originaldaten verlieren

EmptyWorkingSet oder das „Trim Working Set“ eines Tools ist kein Ersatz für VirtualFree oder eine Heap-Freigabe. Fassen Sie dieselbe Seite erneut an, kommt sie per Soft Fault aus Standby oder per Hard Fault aus einem Backing Store zurück. „Ich habe das Working Set verkleinert“ bedeutet also nicht „ich habe das Leck behoben“.

5. Eine saubere Seite geht nach Standby

Auch nachdem eine Seite aus dem Working Set entfernt wurde, kann sie auf Standby gelegt werden, wenn ihre Inhalte noch zur Originaldatei passen oder sie bereits einen sicheren Backing Store hat. Typische Beispiele:

• Unveränderter EXE/DLL-Code
• Eine unveränderte speicherabgebildete Datei
• Eine bereits zurückgeschriebene private Seite
• Im Dateicache verbliebene Daten

Eine Standby-Seite behält ihre Entsprechung zu den vorherigen Inhalten. Wenn derselbe Prozess oder ein anderer diese Inhalte braucht und die Seite noch nicht wiederverwendet wurde, reicht ein Soft Fault, der die PTE wieder verbindet.

Andererseits kann die alte Standby-Identität verworfen und die Seite wiederverwendet werden, wenn eine andere Zuweisung eine physische Seite braucht. Ist das Wiederverwendungsziel eine Benutzermodus-Privatseite, die Nullinitialisierung braucht, wird eine Zeroed-Seite vorbereitet; wird die ganze Seite mit Dateiinhalten oder Ähnlichem überschrieben, kann sie ohne Nullsetzen direkt neu zugewiesen werden.

Genau diese Doppelseitigkeit macht Standby zugleich Cache und Available.

5.1. Warum Available Standby enthält

MEMORYSTATUSEX.ullAvailPhys steht für physischen Speicher, der ohne Schreiben auf die Platte sofort wiederverwendet werden kann, und ist die Summe aus Standby, Free und Zeroed.¹

flowchart LR
    accTitle: Die drei Seitenlisten, die Available bilden
    accDescr: Verfügbarer physischer Speicher ist die Summe aus Standby, Free und Zeroed; im Working Set referenzierte Active-Seiten sind nicht enthalten
    standby["Standby（Wiederverwendungskandidat mit erhaltenem Inhalt）"] --> avail["Available（verfügbarer physischer Speicher）"]
    free["Free（ungenutzt, nicht genullt）"] --> avail
    zeroed["Zeroed（ungenutzt und genullt）"] --> avail
    active["Active（im Working Set referenziert）"] -.->|Nicht enthalten| avail

Abbildung 2: Available ist die Summe aus Standby, Free und Zeroed. Auch Standby, der noch Inhalte hält, zählt als „verfügbar“.

Es ist also kein Widerspruch, wenn der Task-Manager „Free ist niedrig, Cached/Standby aber hoch und Available ausreichend“ zeigt. Windows lässt freien RAM nicht brachliegen; er lässt kürzlich genutzte Dateien und Code auf Standby, damit sie bei Bedarf schnell als Cache wiederverwendet werden können, und nimmt sie, wenn ein anderer Zweck sie braucht.

Schließen Sie nicht „Free ist niedrig, also fehlt sofort Speicher“; betrachten Sie Available, Commit, Hard Faults und Verarbeitungsverzögerung zusammen.

6. Eine schmutzige Seite wartet auf Modified

Wenn eine Anwendung in eine Seite schreibt, passen diese Inhalte nicht mehr zum ursprünglichen Backing Store. Würde man diese schmutzige Seite für einen anderen Zweck überschreiben, gingen die Daten verloren. Eine geänderte, aus dem Working Set entfernte Seite wartet daher auf Modified auf das Zurückschreiben.

Das Zurückschreibziel hängt von der Art der Seite ab.

Microsofts Dokumentation zur Auslagerungsdatei erklärt auch, dass .dll, .exe und gewöhnliche Dateien, die bereits auf der Platte existieren, nicht erneut in die Auslagerungsdatei geschrieben werden müssen, und dass geänderte Daten ohne originale Plattenkopie Kandidaten für die Auslagerungsdatei werden.²

6.1. Der Modified Page Writer

Der Modified Page Writer ist ein System-Worker, der vom Speicher-Manager verfolgte, von der Auslagerungsdatei gestützte schmutzige Seiten scannt und sie in die Auslagerungsdatei schreibt.³ Auf der Seite zugeordneter Dateien gibt es Pfade wie den Mapped Page Writer, die mit Dateisystem und Cache-Manager zusammenarbeiten, um in die zugehörige Datei zurückzuschreiben.

Wichtig ist: Das Herausschreiben ist kein Schema „nichts tun, bis der RAM 0 Byte ist“. Windows bereitet im Hintergrund wiederverwendbare Seiten vor, abhängig von Modified-Liste, Available, Zustand der Auslagerungsdatei und Ähnlichem. Wenn das Zurückschreiben fertig ist und es keine weiteren gültigen Referenzen gibt, geht die Seite mit erhaltenem Inhalt nach Standby.

flowchart TB
    accTitle: Zurückschreibpfade einer geänderten Seite
    accDescr: Eine geänderte Seite, die das Working Set verlässt, wartet auf der Modified-Liste; bei einer privaten Seite schreibt der Modified Page Writer sie bei konfigurierter Auslagerungsdatei in die Auslagerungsdatei, und eine zugeordnete Dateiseite wird vom Mapped Page Writer oder ähnlich in die zugehörige Datendatei zurückgeschrieben und geht dann mit erhaltenem Inhalt nach Standby
    dirty["Geänderte Seite, die das Working Set verlassen hat"] --> modified["Auf der Modified-Liste auf Zurückschreiben warten"]
    modified -->|"Private Seite（bei konfigurierter Auslagerungsdatei）"| mpw["Modified Page Writer schreibt in die Auslagerungsdatei"]
    modified -->|Seite einer zugeordneten Datei| mapped["Mapped Page Writer oder ähnlich schreibt in die zugehörige Datei zurück"]
    mpw --> standby["Nach dem Zurückschreiben nach Standby mit erhaltenem Inhalt"]
    mapped --> standby

Abbildung 3: Das Zurückschreibziel wird durch die Art der Seite bestimmt, und beide Pfade laufen im Hintergrund. Auf einem System mit deaktivierter Auslagerungsdatei hat die private Seite kein Zurückschreibziel, daher bleiben geänderte private Seiten im RAM.

6.2. Seitenausgabe und auslagerungsdateispezifische E/A trennen

Die folgenden Zähler werden leicht verwechselt; klären Sie, was sie bedeuten.

• Memory\\Page Writes/sec: die Anzahl der Paging-Schreib-E/A, die ausgegeben wurden, um physischen Speicher freizumachen
• Memory\\Pages Output/sec: die Anzahl der Seiten, die durch diese Schreibvorgänge auf die Platte geschrieben wurden
• Memory\\Page Reads/sec: die Anzahl der Plattenlese-E/A, die ausgegeben wurden, um Hard Faults aufzulösen
• Memory\\Pages Input/sec: die Anzahl der Seiten, die durch diese Lesevorgänge in den RAM kamen

Beachten Sie, dass Page Writes/sec und Pages Output/sec keine Zähler sind, die allein die Auslagerungsdatei identifizieren. Sie können auch auf dem Pfad steigen, der dateigestützte schmutzige Seiten zurückschreibt, etwa zugeordnete Dateien. Umgekehrt unterscheidet die Eingabeseite ebenfalls nicht zwischen Auslagerungsdatei, DLLs, EXEs und speicherabgebildeten Dateien.² Wollen Sie E/A spezifisch für pagefile.sys identifizieren, schätzen Sie nicht allein aus diesen vier Zählern; zeichnen Sie File I/O und Disk I/O mit ETW/WPA auf und bestätigen Sie die Zieldatei durch Zuordnung von FileObject und FileName.⁹

Noch ein Punkt: Zuerst in die Auslagerungsdatei zu schreiben bedeutet nicht, sofort von der Platte zurückzulesen. Wird die Seite nicht zugegriffen, kann die zurückgeschriebene Seite aus dem RAM entfernt und physischer Speicher an häufiger genutzte Seiten gegeben werden.

7. Der Unterschied zwischen Standby, Free und Zeroed

7.1. Standby

Ein Zustand, der noch die Entsprechung zu den vorherigen Inhalten hält.

• Wenn dieselben Inhalte gebraucht werden, kann sie per Soft Fault zurückkehren
• Wenn ein anderer Zweck sie braucht, kann die alte Identität verworfen und sie wiederverwendet werden
• Es gibt Standby-Listen nach Priorität

7.2. Free

Die gültige Entsprechung zu den vorherigen Inhalten ist verloren, und die Seite ist zuweisbar. Allerdings kann das alte Bitmuster noch in der Seite liegen. Sie unverändert an den Benutzermodus zu übergeben riskiert, Informationen des vorherigen Prozesses durchsickern zu lassen.

7.3. Zeroed

Die Inhalte sind null, und die Seite kann sicher als neue Benutzermodusseite ausgegeben werden. Der Demand-Zero-Fehler aus Teil 1 war ein typischer Fall, eine verfügbare Zeroed-Seite zu holen und an eine PTE zu binden. Die Vorbereitung von Free nach Zeroed erfolgt nach Bedarf und Systemzustand.

Obwohl „Free“ und „Zeroed“ beide ungenutzt wirken, unterscheiden sie sich in der sicherheitsbezogenen Bereitschaft.

8. Der Speicherkompressionsspeicher — im RAM noch ein Ziel schaffen

Ab Windows 10 kann der Speicher-Manager bei Speicherdruck in manchen Fällen selten genutzte Seiten im RAM komprimieren, statt sie sofort auf die Platte zu schreiben. Diese Sammlung komprimierter Seiten ist der Kompressionsspeicher.

In der frühen Windows-10-Implementierung wurde der Kompressionsspeicher im Working Set des System-Prozesses verbucht, auf aktuellem Windows erscheint er in Debugger-Prozesslisten als eigener Memory Compression-Prozess. Untersuchen Sie die aktuelle Kompressionsmenge daher nicht nur über das Working Set des System-Prozesses. Der Zweck selbst — mehr Anwendungen im physischen Speicher zu halten und Platten-E/A zu verringern — hat sich nicht geändert.¹⁰¹¹

Behalten Sie dennoch Folgendes im Blick.

• Komprimierte Seiten nutzen weiterhin RAM
• Kompression und Dekompression haben CPU-Kosten
• Kompression löscht das Commit-Versprechen nicht
• Es gibt keine feste Reihenfolge „immer komprimieren, dann die Auslagerungsdatei“
• Die Richtlinie ändert sich mit Art der Seite, Druck und Zugriffshistorie

„In Verwendung (komprimiert)“ im Task-Manager bedeutet nicht, dass Kompression den physischen Speicher vollständig geleert hat. Der Kompressionsspeicher ist keine Funktion, die die Auslagerungsdatei überflüssig macht; er fügt eine Option hinzu, die CPU nutzt, um E/A zu verringern, zwischen RAM und Speicher.

9. Die eigentliche Rolle der Auslagerungsdatei

Die Auslagerungsdatei hat mindestens drei Rollen.

flowchart LR
    accTitle: Drei Rollen der Auslagerungsdatei
    accDescr: Die Auslagerungsdatei erweitert das Commit Limit, wird zum Backing Store selten genutzter geänderter privater Seiten und wird zur Aufnahme eines Systemabsturzabbilds
    pagefile["Auslagerungsdatei"] --> limit["Commit Limit erweitern（Spielraum an der Decke）"]
    pagefile --> backing["Backing Store für geänderte private Seiten"]
    pagefile --> dump["Aufnahme für ein Systemabsturzabbild"]

Abbildung 4: Die Rolle der Auslagerungsdatei ist nicht nur „langsamer RAM“. Auch bei Nutzung 0 stützt sie noch die Decke und Abbilder.

9.1. Das Commit Limit erweitern

Das Commit Limit des Systems wird grob durch RAM plus die Summe aller Auslagerungsdateien bestimmt. Ohne Auslagerungsdatei sinkt das Commit Limit auf ein Niveau etwas unter dem installierten RAM. Erreicht Commit Total die Decke, schlägt neues Commit fehl und kann zu abnormaler Anwendungsbeendigung oder Systemproblemen führen.⁴

Das ist eine andere Sache als „wie viele GB gerade in pagefile.sys geschrieben sind“. Die Auslagerungsdatei ist auch Spielraum an der Decke, der das Commit-Versprechen stützt.

9.2. Geänderte private Seiten stützen

Werden selten genutzte geänderte private Seiten von der Auslagerungsdatei gestützt, können diese physischen Seiten aus dem RAM entfernt und häufig genutztem Code und Daten gegeben werden.⁴ Das Deaktivieren der Auslagerungsdatei verringert die Option, solche Seiten aus dem RAM zu entfernen. Man kann nicht einfach sagen „es ist schnell, weil kein Auslagern stattfindet“.

9.3. Systemabsturzabbilder stützen

Um bei einem Systemabsturz Memory.dmp zu erzeugen, brauchen Sie eine Auslagerungsdatei oder eine dedizierte Abbilddatei, die die gewählte Abbildmethode stützen kann.² Vollständiges Speicherabbild, Kernel-Speicherabbild und automatisches Speicherabbild unterscheiden sich im benötigten Umfang.

In einer Umgebung, in der Abstürze untersucht werden, kann das Löschen der Auslagerungsdatei nur um Platz zu sparen bedeuten, dass Beweise fehlen, wenn sie am meisten gebraucht werden. Zu Sammelmethoden siehe auch „Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg“.

10. Die richtige Größe ist nicht einheitlich

Die Größe der Auslagerungsdatei sollte nicht allein aus einer festen Formel wie „1,5-facher RAM“ entschieden werden. Microsoft erklärt, dass die angemessene Größe je System bei den folgenden zwei Punkten unterschiedlich ist und nicht verallgemeinert werden kann.²

1. Spitzen-System-Commit-Charge
2. Das benötigte Systemabsturzabbild

In der Praxis in dieser Reihenfolge denken.

10.1. Von Systemverwaltung als Basis starten

Die Windows-Voreinstellung ist systemverwaltet. Sie wächst und schrumpft gemäß installiertem RAM, Commit-Bedarf, Absturzabbildanforderungen und Ähnlichem. Ohne besondere Einschränkung oder Messergebnis ist hier zu starten die sichere Wahl.

10.2. Spitzen-Commit unter repräsentativer Last messen

Erfassen Sie die folgenden Zähler in PerfMon über einen langen Zeitraum.

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

Nehmen Sie tatsächliche Spitzen in den Erfassungszeitraum auf — Monatsendverarbeitung, Sicherungen, Builds, mehrere Benutzer gleichzeitig und so weiter.

Ein hoher Nutzungsprozentsatz der Auslagerungsdatei allein beweist kein Speicherleistungsproblem. An der Decke zu kleben ist jedoch eine Warnung vor unzureichender Kapazität. Betrachten Sie zusammen, ob Commit die Decke nähert, ob viel Modified wartet und ob die Platte gesättigt ist.²

10.3. Zuerst die Abbildanforderung entscheiden

Entscheiden Sie, ob Sie ein vollständiges Speicherabbild brauchen, ob ein Kernel-Speicherabbild reicht oder ob Sie eine dedizierte Abbilddatei nutzen. Wechseln Sie zu einer festen Größe, muss sie nicht nur Spitzen-Commit, sondern auch die Abbildanforderung erfüllen.

11. Selbst nachsehen

11.1. Seitenlisten in RAMMap betrachten

Starten Sie RAMMap als Administrator und öffnen Sie zuerst Use Counts.⁷ Die zu betrachtenden Elemente sind die folgenden.

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summary lässt bestätigen, dass Standby nach Priorität geteilt ist. Processes zeigt das Working Set jedes Prozesses; File Summary und File Details lassen Dateidaten im RAM verfolgen.

Als Versuch lesen Sie einmal eine ziemlich große lokale Datei, beenden Sie das Lesen und dann Refresh. Die Seiten dieser Datei können in File Summary oder auf der Standby-Seite bleiben. Ein erneutes Lesen derselben Datei kann noch nicht wiederverwendete Seiten ohne Platten-E/A oder mit wenig E/A wiederherstellen. Ergebnisse variieren mit Speicherdruck, Antivirus und Dateigröße, daher die Richtung des Zustandsübergangs betrachten, nicht eine einzelne Zahlensammlung.

Beachten Sie, dass das Empty-Menü von RAMMap den Systemzustand künstlich ändert. Leeren Sie Standby nicht als Produktionsleistungsverbesserung; nutzen Sie es nur in einer isolierten Testumgebung.

11.2. Commit und Touch mit Testlimit trennen

Testlimit ist ein Sysinternals-Tool, das Ressourcenknappheit bei Speicher, Handles, Prozessen, Threads und Ähnlichem simuliert. Führen Sie zuerst Folgendes gegen die vorliegende Binärdatei aus und bestätigen Sie die angezeigte Version und Nutzung.

.\\testlimit64.exe -?

Das Folgende zielt auf Testlimit v5.24. In der offiziellen v5.24-Syntax weist -m [MB] die angegebene Speichermenge zu, -d [MB] weist zu und Touch, -e [seconds] ist das Zuweisungsintervall, und -c [count] ist die Zuweisungsanzahl. Geben Sie -c zuletzt an. Weicht das Lokale ab, bevorzugen Sie diese Nutzung.¹²

Als Nächstes klein auf einer Wegwerf-VM ausprobieren.

# -m 64: 64 MiB zuweisen, -e 1: 1-Sekunden-Intervall, -c 8: nach 8 Mal stoppen
.\\testlimit64.exe -m 64 -e 1 -c 8

# Dieselbe Anzahl und dasselbe Intervall, mit -d damit jede Region Touch erhält
.\\testlimit64.exe -d 64 -e 1 -c 8

Während des Laufs gleichzeitig Folgendes aufzeichnen.

• „Zugesichert X/Y“ im Task-Manager
• Active, Modified und Standby in RAMMap
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

Wenn Sie tatsächlich Commit-Erschöpfung nachstellen, tun Sie das nicht auf dem Host-PC; erhöhen Sie die Anzahl schrittweise auf einer VM mit Snapshot. Ein Lauf, der automatisch bis zur Decke zuweist, kann den Bildschirm einfrieren, Prozesse abnormal beenden und Protokolle verlieren. Der Zweck ist nicht, das Betriebssystem zu destabilisieren; er ist zu beobachten, dass beim Nähern an das Commit Limit neues Commit fehlschlägt.

12. Vier Fehldeutungen, die man in der Praxis vermeiden sollte

12.1. „Standby ist hoch, also ist es ein Speicherleck“

Standby ist ein wiederverwendbarer Cache und in Available enthalten. Ein Leck beurteilen Sie danach, ob die prozesseigene Commit-Grundlinie und die Zuweisungsaufschlüsselung auch nach Ende der Last weiterwachsen.

12.2. „Das Working Set zu kürzen behebt das Leck“

Ein Trim ändert nur die Residenz; er gibt weder Commit noch eine virtuelle Zuweisung frei. Beim erneuten Zugriff kommt die Seite per Fault zurück.

12.3. „Die Auslagerungsdatei-Nutzung ist 0, also ist sie unnötig“

Die Auslagerungsdatei stützt nicht nur die aktuelle Schreibmenge, sondern auch das Commit Limit und Absturzabbilder. Die Löschung allein aus dem Alltagsgebrauch zu entscheiden, verliert Spitzenspielraum und Beweise zum Fehlerzeitpunkt.

12.4. „Zuerst Speicherkompression, dann immer die Auslagerungsdatei“

Kompression ist keine feste serielle Pipeline. Windows wählt dynamisch nach Art der Seite, Kompressionseffizienz, CPU-Last, Speicherdruck und ob ein Backing Store existiert.

13. Zusammenfassung

• Die PFN-Datenbank ist das Hauptbuch, das Besitz, Referenzen, Änderung und Seitenlistenzustand einer physischen Seite verfolgt.
• Eine saubere Seite, die das Working Set verlässt, bleibt auf Standby und kann per Soft Fault zurückkehren, wenn dieselben Inhalte gebraucht werden.⁸
• Eine schmutzige Seite wartet auf Modified und wird bei privat in die Auslagerungsdatei, bei zugeordnet in die zugehörige Datei zurückgeschrieben.³
• Available ist die Summe aus Standby, Free und Zeroed; ein großes Standby allein ist kein Speichermangel.¹
• Speicherkompression komprimiert Seiten im RAM, um E/A zu verringern, löscht aber die Rollen von Commit und Auslagerungsdatei nicht.¹⁰
• Die Auslagerungsdatei stützt das Commit Limit, geänderte private Seiten und Systemabsturzabbilder.⁴²
• Die angemessene Größe wird durch Spitzen-Commit und Abbildanforderungen bestimmt; sie lässt sich nicht durch einen einheitlichen Faktor entscheiden.²
• Working-Set-Trimmen und Standby leeren sind keine Speicherleckbehebungen.

Weiter in Teil 3, „Abschnittsobjekte und Copy-on-Write: Was DLLs und Dateizuordnungen wirklich sind“.

Wir verfolgen, warum Dateiseiten und DLLs, die auf Standby bleiben, von mehreren Prozessen als dieselbe physische Seite sichtbar sind.

Weiterführende Artikel

• Die Tiefen des Windows-Speichers (Teil 1) — Der Augenblick, in dem eine virtuelle Adresse zu physischem RAM wird
• Was bedeutet Windows’ „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen
• Die Tiefen von Windows-I/O (Teil 4) — Cache-Manager: Wann erreicht Ihr WriteFile tatsächlich die Festplatte?
• Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg
• Process Explorer / Handle / VMMap in der Praxis — Hängern, Lecks und „Datei wird verwendet“ vom aktuellen Zustand aus nachjagen

Zugehörige Beratungsfelder

KomuraSoft LLC untersucht Speicherdruck in Windows-Anwendungen, Commit-Erschöpfung, Auslagerung, Working-Set-Wachstum und die Gestaltung der Absturzabbilderfassung.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Migration bestehender Assets
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wird eine Seite sofort in die Auslagerungsdatei geschrieben, sobald sie das Working Set verlässt?

Nein. Eine unveränderte Seite wandert mit erhaltenem Inhalt nach Standby und wird ein sofort wiederverwendbarer Cache. Eine geänderte Seite wandert nach Modified und geht nach dem bedarfsweisen Zurückschreiben in die Auslagerungsdatei oder die zugehörige Datei in einen wiederverwendbaren Zustand wie Standby über.

Enthält „Verfügbar“ im Task-Manager Standby-Speicher?

Ja. Der verfügbare physische Speicher, den Windows meldet, ist die Summe aus Standby, Free und Zeroed. Standby hält noch alte Inhalte, zählt aber als verfügbarer Speicher, weil er bei Bedarf sofort für einen anderen Zweck wiederverwendet werden kann.

Beginnt das Schreiben in die Auslagerungsdatei erst, wenn der RAM vollständig erschöpft ist?

Nein. Windows schreibt selten genutzte geänderte Seiten im Hintergrund zurück, abhängig von der Modified-Liste und dem Zustand des verfügbaren Speichers. Es ist kein einfacher Mechanismus, der absolute Erschöpfung abwartet und dann alles auf einmal verdrängt.

Wird Windows schneller, wenn man die Auslagerungsdatei deaktiviert?

Das lässt sich nicht allgemein behaupten. Das Deaktivieren senkt das Commit Limit, erschwert das Entfernen selten genutzter geänderter Seiten aus dem RAM und wirkt sich auch auf Systemabsturzabbilder aus. Normalerweise belässt man sie systemverwaltet und entscheidet anhand von Spitzen-Commit und Abbildanforderungen.

Macht Speicherkompression die Auslagerungsdatei überflüssig?

Sie wird nicht überflüssig. Ein Kompressionsspeicher komprimiert Seiten im RAM, um E/A zu verringern, aber komprimierte Seiten nutzen weiterhin physischen Speicher und ersetzen die Commit-Garantie nicht. Die Wahl zwischen Kompression und Auslagerung ist eine dynamische Richtlinie des Speicher-Managers.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.