Warum nimmt meine Seitentabelle so viel Speicherplatz ein?

Mein 64-Bit-Windows 7-PC ist sehr träge. Ich habe im Task-Manager festgestellt, dass meine Speichernutzung nahezu 100% beträgt. Die für jeden Prozess gemeldete Auslastung summiert sich jedoch nicht auf insgesamt 6 GB (Firefox zeigt etwa 500 MB an, der Rest viel weniger). Ich heruntergeladen RAMMap und festgestellt , dass die Seite Tabelle wird eine beträchtliche Menge an Speicher (2,5 GB) einnimmt.

Ich habe das gegoogelt und bin nirgendwo hingekommen - anscheinend kann die Seitentabelle fragmentiert werden. Natürlich werde ich die Maschine neu starten und sehen, ob das hilft. Aber gibt es einen besseren Weg, dies zu beheben?

BEARBEITEN: Neustart und die Seitentabelle ist auf 30 MB reduziert.

BEARBEITEN 2: Nach einigen Tagen Betriebszeit schleicht sich die Verwendung der Seitentabelle wieder ein. Ich habe die Anweisungen von @ magicandre1981 in dieser Antwort befolgt , um die Quelle für die Verwendung der Seitentabelle zu finden. Leider habe ich ein Leerzeichen gezeichnet - die Seitentabelle wird von "Unbekannt" verwendet!

Hat jemand gute Ideen?

Ich muss die Kommentare zur Frage kommentieren, insbesondere die Verwechslung zwischen "Seitentabelle" und "Auslagerungsdatei". Dies ist keine Antwort, passt aber nicht in den für Kommentare zulässigen Bereich.

"Seitentabelle" ist in der Tat eine ganz andere Sache als die Auslagerungsdatei. Wenn n MB RAM für Seitentabellen verwendet werden, bedeutet dies nicht, dass Sie n MB Auslagerungsspeicherplatz verwenden. Und obwohl einige Seitentabelleneinträge (PTEs, aus denen Seitentabellen bestehen) auf den Inhalt von Auslagerungsdateien verweisen, tun dies nicht alle.

Die Seitentabellen sind speicherinterne Strukturen, die von der MMU der CPU verwendet werden, um die Adressumsetzung von virtuellen Adressen (wiederum nicht der Auslagerungsdatei) in physische Adressen durchzuführen, und vom Betriebssystem, um den virtuellen Adressraum zu verfolgen und Seitenfehler zu beheben. Seitentabellen bestehen aus Seitentabelleneinträgen (PTEs). Jeder PTE belegt 8 Bytes und definiert 4 KByte virtuellen Adressraum - dh eine virtuelle Seite. Es gibt ungefähr einen PTE für jede nicht freie Seite des virtuellen Adressraums.

Übrigens, obwohl die Auslagerungsdatei sowohl eine externe als auch eine interne Fragmentierung aufweisen kann (die erstere ist normalerweise kein großes Problem; die letztere kann verbessert werden, indem sie etwa viermal so groß gemacht wird, wie sie sein muss), können Seitentabellen dies jedoch nicht. Sie sind schon immer fragmentiert, und das spielt keine Rolle.

Jeder PTE hat ein "gültiges" Bit. Für "gültige", auch "residente" Seiten genannt, enthält der PTE die physische Seitenzahl, die der virtuellen Seitenzahl entspricht, die dem PTE zugeordnet ist. Dies wird direkt von der MMU verwendet.

Für "ungültige" Seiten löst die MMU einen Seitenfehler aus und die PTE hat dann viele mögliche Formate und Interpretationen.

Hinweis: Alle oben genannten Punkte gelten für alle Betriebssysteme, die Paging unter x86 / x64 ermöglichen. Das Folgende ist weitgehend spezifisch für Windows, aber viele der Konzepte gelten für andere Betriebssysteme, mit Unterschieden in den Details der Implementierung.

Für eine Seite im Seitencache enthält der PTE weiterhin die physische Seitenzahl. Für Seiten, die aus dem RAM verloren gegangen sind und in die Auslagerungsdatei geschrieben wurden, enthält der PTE die Auslagerungsnummer und den Versatz in der Auslagerungsdatei, in die der Seiteninhalt geschrieben wurde. Andere mögliche PTE Inhalte sind Verweise auf virtuelle Adresse Deskriptoren , Verweise auf „Prototyp PTEs“, Verweise auf Null verlangen Seiten usw., die ich nicht in Gang zu bringen. Es genügt zu sagen, dass sich nur einige der PTEs auf Speicherorte in Auslagerungsdateien beziehen.

Ich erwähne dies alles hauptsächlich, um zu zeigen, dass die Auslagerungsdatei und die Seitentabellen, obwohl sie miteinander verbunden sind, definitiv nicht dasselbe sind.

Seitentabellen sind in einer Baumstruktur organisiert. Für jeden Prozess gibt es einen anderen solchen Baum oder eine andere Sammlung von Seitentabellen. Auf diese Weise kann jeder Prozess seine eigene Instanz des virtuellen Adressraums definieren. Die Seitentabelle im Stammverzeichnis des Baums muss sich immer im RAM befinden. Die anderen sind pageable; Sie sind sogar nicht vorhanden, wenn sie großen (mindestens 2 MB) Regionen undefinierten oder freien virtuellen Adressraums entsprechen würden.

Die Seitentabelleneinträge in den Tabellen an den "Blättern" des Baums entsprechen Seiten des virtuellen Adressraums. Die PTEs in den übergeordneten Tabellen - diejenigen, die näher an der Wurzel (und der Wurzel selbst) liegen - geben an, wo sich die nächstniedrigeren Tabellen befinden (falls überhaupt vorhanden).

Die von RAMmap angezeigte Nummer ist der physische Speicher (RAM), der von allen residenten (In-RAM) Seitentabellen für alle Prozesse plus das Betriebssystem belegt wird.

Wichtig ist hierbei, dass auf dem System im OQ 2,5 GB RAM mit Seitentabellen verknüpft waren. Das bedeutet, dass mindestens 2,5 GB Seitentabellen definiert sind. Da Seitentabellen selbst pageable sind, kann die virtuelle Größe viel größer sein als die physische Größe, die RAMmap nur anzeigen kann. Aber nehmen wir an, es sind "nur" 2,5 GB. Bei acht Bytes pro PTE sind das ungefähr 320 Millionen PTEs. Da jeder PTE eine Seite - 4 KByte - des virtuellen Adressraums definiert, bedeutet dies, dass über 1,2 Terabyte des virtuellen Adressraums durch speicherinterne Seitentabellen definiert werden.

Das ist nicht unmöglich, aber es ist ziemlich viel.

Als Referenz habe ich auf meinem System atm ungefähr 125 MB RAM in Seitentabellen. Dies würde nur etwa 65 GB virtuellen Adressraum anzeigen. Meine tatsächliche virtuelle Nutzung ist viel höher (125 TB nur für Prozesse), aber das liegt daran, dass sich die meisten Seitentabellen nicht im RAM befinden. "Große Seiten", eine andere Sache, auf die ich hier nicht eingehen sollte, kann auch dazu beitragen, unterschiedliche Verhältnisse zwischen der Größe von Seitentabellen und der Größe des verwendeten virtuellen Adressraums zu berücksichtigen.

Also: Um den Schuldigen zu finden, würde ich zuerst im Leistungsmonitor unter der Kategorie Prozess nach Prozessen mit einem hohen Zählerwert für "virtuelle Bytes" suchen.

Lenovo "RapidBoot Shield" war der Schuldige für mich.

Nach einer Woche ohne Neustart verwendete meine "Seitentabelle" 4 GB +. Es stellte sich heraus, dass jeder abgeschlossene Prozess mit 20 KB RAM (4 KB privat, 16 KB Seitentabelle), wie auf der Registerkarte "Prozesse" von RamMap gezeigt, nicht funktioniert hat, und es gab ~ 200.000 davon!

Durch einen Neustart wurde die Liste reduziert, aber sie begann wieder zu wachsen. Es war reproduzierbar, indem der Editor geöffnet, getötet und festgestellt wurde, dass er in der RamMap-Prozessliste verbleibt.

Aufgrund von Vorschlägen zu diesem Technet-Thread habe ich "RapidBoot Sheild" deinstalliert, den Computer neu gestartet und die Prozesse blieben nicht mehr bestehen, wenn sie beendet wurden. Problem gelöst!

In meinem Fall waren dies Aksdf.sys- und Hardlock.sys-Filtertreiber von Aladdin Knowledge Systems Aladdin-Treibern . Ich habe es geschafft, diese Antwort auch mit RAMMap zu finden. Es zeigte den Speicher an, der vom abgebrochenen Prozess verbraucht wurde. Die Prozesse wurden aus der Windows-Prozessliste entfernt, blieben jedoch in der Speicherzuordnung erhalten. Die Treiber scheinen eine vollständige Beendigung der Prozesse zu verhindern.

Ich habe meine IT-Abteilung danach gefragt, und sie waren ähnlich bamboozled. Am Ende habe ich DriverEasy verwendet , um meine Treiber zu aktualisieren. Seltsamerweise schienen die Monitortreiber den Unterschied zu machen. Zuvor hatte ich die Standardtreiber für Windows "Generic PnP Monitor". Aber als ich diese auf die richtige Marke und das richtige Modell meiner Monitore aktualisierte, schien das Problem zu verschwinden.

Öffnen Sie die Registerkarte "Prozesse" in RamMap und sortieren Sie nach Namen. Suchen Sie nach einer verdächtig hohen Anzahl desselben Prozesses. Auf meinem Computer war "SynTPEnh.exe" der Schuldige (ein Teil des Touchpad-Treibers). Nach einer Woche Betriebszeit wurden Zehntausende von Einträgen in der Seitentabelle mit einer Größe von jeweils 32 KB gesammelt.

Meine Seitentabellengröße betrug 1 GB, nach einem Neustart sind es nur 50 MB.