Kurze Antwort

Die" out of memory "Pop-up sagt Ihre' e läuft aus der Grenze auf private Commited Speicher-eine Art von virtuellem Speicher. Nicht, dass Ihnen der RAM (physischer Speicher) ausgeht. Es spielt keine Rolle, wie viel verfügbarer RAM Sie haben. Mit viel verfügbarem RAM können Sie das Commit-Limit nicht überschreiten. Das Commit-Limit ist die Summe Ihres gesamten RAM (ob verwendet oder nicht!) plus Ihre aktuelle Pagefile-Größe.

Umgekehrt, was "verwendet up " Commit-Limit (das ist meist die Schaffung von Prozess-privaten virtuellen Adressraum) verwendet nicht unbedingt RAM! Aber das Betriebssystem lässt seine Erstellung nicht zu, es sei denn, es weiß, dass es einen Ort zum Speichern gibt, wenn es jemals benötigt wird. So können Sie auf das Commit-Limit stoßen, ohne Ihren gesamten RAM oder sogar den größten Teil Ihres RAM zu verwenden.

Deshalb solltest du nicht ohne Pagefile laufen. Beachten Sie, dass das Pagefile möglicherweise nie geschrieben wird! Aber es wird immer noch lassen sie vermeiden die " low auf speicher" und "out of memory" Fehler.

Zwischenantwort

Windows hat eigentlich keine Fehlermeldung, dass der Arbeitsspeicher knapp wird. Was Ihnen ausgeht, ist "Commit Limit".

Das" System " - Diagramm in dieser Version von Process Explorer ist schlecht benannt. Es sollte mit "Commit charge"gekennzeichnet sein. (In der Version, die ich habe, heißt es "System Commit". Besser, aber immer noch nicht ganz konsistent.) In jedem Fall die "aktuelle" Höhe des Graphen gibt es, was unten im Text zeigt abschnitt als "Commit Charge" - "Current", und die maximale Höhe des Graphen stellt" Commit Charge " - "Limit".

"Commit charge" bezieht sich auf den virtuellen Adressraum, der von der Auslagerungsdatei unterstützt wird (falls Sie eine haben) - mit anderen Worten, wenn nicht alles in den Arbeitsspeicher passt, wird der Rest in die Auslagerungsdatei übernommen. (Es gibt andere Arten von v. a. s., die entweder von anderen Dateien gesichert werden - das heißt "abgebildet" v. a. s.-oder die die ganze Zeit im RAM bleiben müssen; Letzteres wird als "nicht bearbeitbar"bezeichnet.) "Begehen limit " ist das Maximum, das die "Commit Charge" sein kann. Es entspricht Ihrer RAM-Größe plus der Pagefile-Größe.

Sie haben anscheinend keine Auslagerungsdatei (ich kann sagen, weil Ihr Commit-Limit Ihrer RAM-Größe entspricht), daher ist das Commit-Limit einfach die RAM-Größe.

Anscheinend haben verschiedene Programme + das Betriebssystem fast alle maximal möglichen Commits verwendet.

Dies hat nichts direkt damit zu tun, wie viel RAM frei oder verfügbar ist. Ja, Sie haben etwa 4,5 GB RAM zur Verfügung. Das bedeutet nicht bedeutet, dass Sie das Commit-Limit überschreiten können. Festgeschriebener Speicher verwendet nicht unbedingt RAM und ist nicht durch die Menge des verfügbaren RAM begrenzt.

Sie müssen entweder die Auslagerungsdatei erneut aktivieren - mit so viel Engagement würde ich eine 16-GB-Auslagerungsdatei vorschlagen, da Sie das Betriebssystem nicht zwingen möchten, so viel davon im RAM zu behalten, und die Auslagerungsdatei funktioniert am besten, wenn es viel freien Speicherplatz hat - oder fügen Sie mehr RAM hinzu. VIEL mehr. Für eine gute Leistung benötigen Sie viel Platz im RAM für code und andere Dinge, die nicht von der Auslagerungsdatei gesichert werden (aber in andere Dateien ausgelagert werden können).

Sehr Lange Antwort

(aber immer noch viel kürzer als das Kapitel Speicherverwaltung von Windows Internals...)

Angenommen, ein Programm weist 100 MB prozessprivaten virtuellen Speicher zu. Dies geschieht mit einem virtualalalloc-Aufruf mit der Option "commit". Dies führt zu einer Erhöhung der "Commit Charge"um 100 MB. Aber diese "Zuordnung" verwendet eigentlich keinen RAM! RAM wird nur verwendet, wenn auf einige dieser neu festgeschriebenen virtuellen Adressräume zum ersten Mal zugegriffen wird.

Wie der RAM schließlich verwendet wird

(wenn überhaupt)

Der erstmalige Zugriff auf den neu festgeschriebenen Speicherplatz wäre fast immer ein Speicherschreiben (das Lesen neu zugewiesener privater VVS vor dem Schreiben ist fast immer ein Programmierfehler,da der ursprüngliche Inhalt streng genommen undefiniert ist). Aber lesen oder schreiben, das Ergebnis, das erste Mal, wenn Sie eine Seite berühren neu zugewiesene v. a. s., ist ein Seitenfehler. Obwohl das Wort "Fehler" schlecht klingt, sind Seitenfehler ein völlig erwartetes und sogar erforderliches Ereignis in einem virtuellen Speicherbetriebssystem.

Als Reaktion auf diese bestimmte Art von Seitenfehler, der Pager (Teil des Speichermanagers des Betriebssystems, den ich manchmal abkürzen werde. als "Mm") wird:

1. Ordnen Sie eine physische Seite RAM zu (idealerweise aus der Nullseitenliste, aber auf jeden Fall kommt es von dem, was Windows als "verfügbar" bezeichnet: Null, frei oder (seitenliste, in dieser Reihenfolge der Präferenz);
2. Füllen Sie einen Seitentabelleneintrag aus, um die physische Seite der virtuellen Seite zuzuordnen; und schließlich
3. Schließen Sie die Seitenfehlerausnahme.

Danach wird der Code, der die Speicherreferenz ausgeführt hat, die Anweisung erneut ausführen, die den Seitenfehler ausgelöst hat, und diesmal wird die Referenz erfolgreich sein.

Wir sagen, dass die Seite in den Prozess-Arbeitssatz und in den RAM" fehlerhaft " wurde. Im Task-Manager dieses erscheint als einseitige (4 KB) Erhöhung des "privaten Arbeitssatzes" des Prozesses. Und eine einseitige Reduzierung des verfügbaren physischen Speichers. (Letzteres kann auf einer ausgelasteten Maschine schwer zu bemerken sein.)

Hinweis 1: Bei diesem Seitenfehler wurde nichts von der Festplatte gelesen. Eine nie zuvor aufgerufene Seite mit festgeschriebenem virtuellem Speicher beginnt nicht auf der Festplatte; es hat keinen Platz auf der Festplatte, um es zu lesen von. Es wird einfach in einer zuvor verfügbaren RAM-Seite" materialisiert". Statistisch gesehen werden die meisten Seitenfehler tatsächlich im RAM behoben, entweder für freigegebene Seiten, die sich bereits im RAM für andere Prozesse befinden, oder für die Seitencaches - die Standby-oder modifizierten Listen oder als "Demand Zero" - Seiten wie diese.

Hinweis 2: Dies dauert nur eine Seite, 4096 Bytes, von "Verfügbar". Nie berührt-bevor der Adressraum normalerweise realisiert wird-fehlerhaft-nur eine Seite nach der anderen, da jede Seite zum ersten Mal "berührt" wird. Es würde keine Verbesserung geben, nein vorteil, mehr zu einer Zeit zu tun; es würde nur n mal so lange dauern. Im Gegensatz dazu, wenn Seiten von der Festplatte gelesen werden müssen, wird eine gewisse Menge an "Readahead" versucht, da die überwiegende Mehrheit der Zeit in einem Plattenlesevorgang pro Betrieb Overhead ist, nicht die tatsächliche Datenübertragung. Der Betrag" Commited " bleibt bei 100 MB; Die Tatsache, dass eine oder die Seiten fehlerhaft sind, verringert die Commit-Gebühr nicht.

Hinweis 3: Nehmen wir an, wir haben 4 GB" verfügbares " RAM. Das heißt, wir könnten verweisen Sie auf bereits zugewiesenen, aber nie zuvor referenzierten festgeschriebenen Speicher etwa eine Million Mal (4 GB / 4096), bevor wir keinen RAM mehr haben. An diesem Punkt, wenn wir eine Auslagerungsdatei haben, wie David Cutler und Lou Perazzoli beabsichtigten, würden einige der Seiten, auf die vor langer Zeit im RAM verwiesen wurde, auf der Festplatte gespeichert und dann zur Lösung dieser neueren Seitenfehler zur Verfügung gestellt. (Eigentlich würde das Betriebssystem RAM-Reclamationsmethoden wie "working Set Trimmen" eher vorher initiieren, und das eigentliche schreibt an die Auslagerungsdatei wird in der geänderten Seitenliste zwischengespeichert und stapelweise abgelegt, um die Effizienz zu erhöhen, und und... ) Nichts davon würde die Anzahl der "engagierten" beeinflussen. Es ist jedoch relevant für das "Commit-Limit". Wenn nicht der gesamte "festgeschriebene" Speicher im RAM vorhanden ist, kann der Überschuss in der Auslagerungsdatei gespeichert werden. Somit trägt die Größe der Auslagerungsdatei zum "Commit-Limit"bei.

Und es passiert immer wieder...

Aber nehmen wir an, wir haben diese Millionen weiteren Referenzen nicht gemacht und es gibt immer noch etwa 4 GB wert von Seiten "verfügbar". Nehmen wir nun an, derselbe Prozess-oder ein anderer, spielt keine Rolle - führt ein anderes VirtualAlloc durch, diesmal beispielsweise 200 MB festgeschrieben. Auch diese 200 MB werden zur Commit-Gebühr hinzugefügt und entfernen keinen verfügbaren RAM. Einfach VirtualAlloc 'oating Adressraum verbraucht nicht eine entsprechende Menge an RAM, und mit niedrigen" verfügbar " RAM begrenzt nicht die Menge an Adressraum können Sie Virtualloc (noch mit hohen verfügbaren RAM erhöhen).

(Gut, Okay... es gibt ein kleines bisschen Overhead, der einem entspricht (pageable!) Seite, die für eine Seitentabelle für jeweils 2 MB (4 MB, wenn Sie sich auf einem x86 -, Nicht-PAE-System befinden) virtuellen Adressraum verwendet wird, und es gibt einen "virtuellen Adressdeskriptor" von einigen zehn Bytes für jeden virtuell zusammenhängenden zugewiesenen Bereich.)

Auf diese Weise ist es möglich-und üblich! - um eine Menge "Commit Charge" zu verbrauchen, während nur kleine Mengen an RAM verwendet werden.

Also, wenn virtueller Adressraum "festgeschrieben" wird verbraucht keinen RAM, warum muss es ein Limit geben?

Weil die "Commit Charge" eine potenzielle [[4]}zukünftige [[5]} Nutzung von Speicherplatz darstellt. "Commit Limit" stellt die Gesamtmenge an Speicher (RAM + Pagefile-Speicherplatz) dar, die für solche Zuordnungen verfügbar ist, sollten sie jemals tatsächlich referenziert werden und von dort irgendwo gespeichert werden müssen.

Wenn das Mm eine Virtualalalloc-Anforderung genehmigt, verspricht es - "eine Verpflichtung eingehen" -, dass alle nachfolgenden Speicherzugriffe auf der zugewiesene Bereich wird erfolgreich sein; Sie können zu Seitenfehlern führen, aber die Fehler können alle behoben werden, da genügend Speicherplatz vorhanden ist, um den Inhalt all dieser Seiten zu speichern, sei es im RAM oder in der Auslagerungsdatei. Der Mm weiß dies, weil er weiß, wie viel Speicherplatz vorhanden ist (das Commit-Limit) und wie viel bereits "festgeschrieben" wurde (die aktuelle Commit-Gebühr).

(Aber auf all diese Seiten wurde noch nicht unbedingt zugegriffen, daher gibt es nicht unbedingt eine tatsächliche von lagerung mit dem Betrag verpflichtet zu gehen, zu einem bestimmten Zeitpunkt.)

So... Was ist mit "System ist aus dem Speicher"?

Wenn Sie versuchen, virtualalalloc und die aktuelle Commit-Gebühr plus die angeforderte Zuweisungsgröße virtualalalloc würden Sie das Commit-Limit überschreiten, UND das Betriebssystem kann das Pagefile nicht erweitern, um das Commit-Limit zu erhöhen... sie erhalten das Popup" Out of memory " und der Prozess sieht, dass der VirtualAlloc-Aufruf FEHLSCHLÄGT. Die meisten Programme werfen nur ihre Hände und sterben an diesem Punkt. Einige werden drücken Sie blind darauf, vorausgesetzt, der Anruf ist erfolgreich, und schlagen Sie später fehl, wenn sie versuchen, auf die Region zu verweisen, von der sie dachten, sie hätten sie zugewiesen.

Nochmal (Entschuldigung für die Wiederholung): Es spielt keine Rolle, wie viel RAM Sie zur Verfügung haben. Das Betriebssystem hat versprochen, dass der RAM-oder Pagefile-Speicherplatz verfügbar sein wird, wenn er benötigt wird, aber dieses Versprechen subtrahiert nicht von "Verfügbar". Verfügbarer Arbeitsspeicher wird nur von festgeschriebenen VM verbraucht, wenn auf zum ersten Mal auf verwiesen wird. bewirkt, dass es "fehlerhaft" ist... dh im physischen Speicher realisiert. Und einfach virtuellen Speicher festschreiben (= zuweisen) tut das nicht. Es nimmt nur freien virtuellen Adressraum ein und macht daraus nutzbaren virtuellen Adressraum.

Aber im Fall "Out of Memory" gab es eine Zuweisungsanforderung für festgeschriebenen Speicher, und das Betriebssystem hat die aktuelle Festschreibungsgebühr zur Größe dieser neew-Anforderung hinzugefügt... und festgestellt, dass die Summe mehr als das Commit-Limit ist. Also, wenn das Betriebssystem genehmigt dieser neue, und all dieser Raum wurde danach referenziert, es würde keine realen Orte (RAM + pagefile) geben, um alles zu speichern.

Das Betriebssystem lässt dies nicht zu. Es werden nicht mehr v. a. s. zugewiesen, als Platz haben, um es im schlimmsten Fall zu behalten-auch wenn alles "fehlerhaft" wird."Das ist der Zweck des"Commit Limit".

Ich sage es dir dreimal Ich sage es dir dreimal Ich sage es dir dreimal: Die Menge an "verfügbarem" RAM spielt keine Rolle. Dass der festgeschriebene virtuelle Raum nutzt noch nicht den gesamten Speicherplatz, spielt keine Rolle. Windows kann sich nicht auf die virtuelle Zuordnung" festlegen", es sei denn, es" kann " in Zukunft alles fehlerhaft sein.

Hinweis Es gibt eine andere Art von v. a. s., die als "mapped" bezeichnet wird und hauptsächlich für Code und den Zugriff auf große Datendateien verwendet wird, jedoch nicht für "Commit Charge" berechnet wird und nicht durch das "Commit Limit"begrenzt ist. Dies liegt daran, dass es einen eigenen Speicherbereich hat, die Dateien, die ihm "zugeordnet" sind. Der das einzige Limit für" zugeordnete " v. a. s. ist die Menge an Speicherplatz, die Sie für die zugeordneten Dateien haben, und die Menge an freien v. a. s. in Ihrem Prozess, um sie zuzuordnen.

Aber wenn ich mir das System ansehe, bin ich noch nicht ganz am Commit-Limit?

Das ist im Grunde ein Mess-und Aufzeichnungsproblem. Sie betrachten das System, nachdem ein virtualalalloc-Aufruf bereits versucht wurde und fehlgeschlagen ist.

Angenommen, Sie hatten nur noch 500 MB Commit-Limit und ein Programm hatte versucht, virtualalalloc 600 MB. Der Versuch schlägt fehl. Dann schaust du dir das System an und sagst "Was? Es sind noch 500 MB übrig!"In der Tat könnte bis dahin noch viel mehr übrig sein, da der fragliche Prozess wahrscheinlich bis zu diesem Zeitpunkt vollständig verschwunden ist, sodass der gesamte zuvor zugewiesene festgeschriebene Speicher freigegeben wurde.

Das Problem ist, dass Sie nicht in der Zeit zurückblicken und sehen können, was die Commit Charge war in dem Moment, in dem der Alloc-Versuch gemacht wurde. Und Sie wissen auch nicht, wie viel Platz der Versuch hat war für. Sie können also nicht definitiv sehen, warum der Versuch fehlgeschlagen ist oder wie viel mehr "Commit-Limit" erforderlich gewesen wäre, damit es funktioniert.

Ich habe gesehen, "system schwach on memory". Was ist das?

Wenn das Betriebssystem im obigen Fall die Auslagerungsdatei erweitern kann (dh Sie belassen sie bei der Standardeinstellung "System managed", oder Sie verwalten sie, aber Sie setzen das Maximum auf größer als die Initiale UND es gibt genügend freien Speicherplatz), und eine solche Erweiterung erhöht das Commit-Limit genug, um den virtualalalloc-Aufruf dann erfolgreich sein zu lassen... das Mm erweitert die Auslagerungsdatei und der Aufruf von VirtualAlloc ist erfolgreich.

Und dann sehen Sie "Das System hat wenig Speicher". Das ist eine frühe Warnung, dass, wenn die Dinge ohne Abschwächung weitergehen, Sie wahrscheinlich bald eine "Out of Memory" Warnung sehen werden. Zeit, einige Apps zu schließen. Ich würde mit Ihren Browserfenstern beginnen.

Und Sie denken, das ist eine gute Sache? Pagefile Erweiterung ist böse!!!

Nein, das ist es nicht. "erweitert" die vorhandene Datei nicht wirklich. Es weist nur ein neues Ausmaß zu. Der Effekt ist ähnlich wie bei jeder anderen nicht zusammenhängenden Datei. Die alten Pagefile-Inhalte bleiben genau dort, wo sie sind; Sie müssen nicht an einen neuen Ort oder ähnliches kopiert werden. Da sich die meisten Pagefile IO im Vergleich zur Pagefile-Größe in relativ kleinen Blöcken befinden, sind die Chancen, dass eine bestimmte Übertragung eine Ausdehnungsgrenze überschreitet, wirklich ziemlich selten, sodass die Fragmentierung nicht viel schadet, es sei denn, sie ist wirklich übermäßig.

Sobald alle Prozesse, die Speicherplatz in der Erweiterung" festgeschrieben " haben, beendet wurden (beim Herunterfahren des Betriebssystems, wenn nicht früher), werden die Ausmaße stillschweigend freigegeben und die Auslagerungsdatei kehrt zu ihrer vorherigen Größe und Zuweisung zurück - wenn es vorher zusammenhängend war, ist es wieder so.

Das Zulassen der Pagefile-Erweiterung fungiert daher als völlig freies Sicherheitsnetz: Wenn Sie es zulassen, das System es jedoch nie benötigt, wird das System die Pagefile nicht wie so oft "ständig erweitern und zusammenziehen behauptet, also kostet es nichts. Und wenn Sie es jemals brauchen, werden Sie vor Apps bewahrt, die mit Fehlern "Außerhalb des virtuellen Speichers" abstürzen.

Aber, aber, aber...

Ich habe auf Dutzenden von Websites gelesen, dass, wenn Sie Pagefile-Erweiterungsfenster zulassen, das Pagefile ständig erweitert und zusammengezogen wird und dass dies zu einer Fragmentierung des Pagefiles führt, bis Sie es defragmentieren.

Sie liegen einfach falsch.

Wenn Sie noch nie gesehen haben, die "running low on memory" (bzw., in älteren Versionen ("running low on virtual Memory") Pop-up, hat das Betriebssystem nie Ihre Pagefile erweitert.

Wenn Sie dieses Pop-up sehen, dann sagt Ihnen das, dass Ihre anfängliche Auslagerungsdatei zu klein ist. (Ich stelle es gerne auf etwa das Vierfache der maximal beobachteten Nutzung ein; dh der Perfmon-Zähler "%pagefile usage peak" sollte unter 25% liegen. Grund: Pagefile-Speicherplatz wird wie jeder andere Heap verwaltet und funktioniert am besten mit viel freiem Speicherplatz zum Abspielen.)

Aber warum nicht einfach...

Könnte Man argumentieren Sie, dass das Betriebssystem die Zuweisung einfach zulassen und dann die Referenzen fehlschlagen lassen sollte, wenn kein RAM verfügbar ist, um die Seitenfehler zu beheben. Mit anderen Worten, oben, wo wir beschrieben haben, wie der anfängliche Seitenfehler funktioniert, was wäre, wenn die "Zuweisung einer verfügbaren physischen RAM-Seite" (Schritt 1) nicht möglich wäre, da keine verfügbar war, und Es gab keinen Platz mehr, um irgendetwas auszulagern, um etwas verfügbar zu machen?

Dann kann der Pager die Seite nicht auflösen Fehler. Es müsste zulassen, dass die Ausnahme (der Seitenfehler) an den fehlerhaften Thread zurückgemeldet wird, wahrscheinlich in einen anderen Ausnahmecode geändert.

Die Designphilosophie ist, dass VirtualAlloc Null (technisch einen Nullzeiger) anstelle einer Adresse zurückgibt, wenn das Commit-Limit überschritten wird, und es ist völlig vernünftig zu erwarten, dass der Programmierer weiß, dass ein VirtualAlloc-Aufruf fehlschlagen kann. Es wird also von Programmierern erwartet, dass sie nach diesem Fall suchen und als Antwort etwas Vernünftiges tun (wie geben Sie eine Chance, Ihre Arbeit bis zu diesem Punkt zu speichern, und beenden Sie dann das Programm "anmutig"). (Programmierer: Sie suchen nach einer Nullzeigerrückgabe von malloc, new usw., ja? Warum sollten Sie dann nicht davon?)

Aber Programmierer sollten nicht erwarten müssen, dass eine einfache Speicherreferenz wie

i = 0;             // initialize loop counter

Schlägt möglicherweise fehl - nicht, wenn es sich in einem Bereich mit erfolgreich festgeschriebenem Adressraum befindet. (Oder zugeordneter Adressraum, für diese Angelegenheit.- ) Aber das ist, was passieren könnte, wenn die "zulassen überlastet zuweisen, lassen Sie die Speicher-Referenz-Fehler" - Philosophie folgte.

Leider hat eine Speicherreferenz wie die in der obigen Codezeile einfach keine bequeme Möglichkeit, einen schlechten Status zurückzugeben! Sie sollen nur funktionieren, genau wie Addition und Subtraktion. Die einzige Möglichkeit, solche Fehler zu melden, wären Ausnahmen. Um damit umzugehen, müsste der Programmierer das gesamte Programm in einen Ausnahmebehandler einschließen. (versuchen ... fang und alle dass.)

Das kann getan werden... Es wäre jedoch schwierig für den Handler zu wissen, wie er als Antwort auf diese Ausnahmen "das Richtige tut", da der Code so viele Punkte enthalten würde, an denen sie auftreten könnten. (Insbesondere könnten sie bei bei jedem - Speicherverweis auf virtualalalloc ' d-Speicher, auf mit malloc oder new zugewiesenen Speicher auftreten... und auch für alle lokalen Variablen, da der Stack auch VirtualAlloc ist.)

Kurz gesagt, wodurch das Programm anmutig in fehlschlägt diese Fälle wären sehr schwierig.

Es ist andererseits ziemlich einfach, nach einer Nullzeigerrückgabe von virtualalalloc (oder malloc oder new, obwohl sie nicht genau dasselbe sind) zu suchen und dann etwas Vernünftiges zu tun... wie nicht versuchen, weiterzumachen und zu tun, wofür das Programm diesen virtuellen Raum benötigte. Und vielleicht fragen Sie den Benutzer, ob er seine Arbeit so weit speichern möchte, falls vorhanden. (Zugegeben, viel zu viele Apps machen sich nicht einmal so viel Mühe.)

Andere benutzer von commit

Übrigens wird das "Commit-Limit" nicht durch die verschiedenen Zuordnungen des Betriebssystems wie den Paged-und Nonpaged-Pool, die PFN-Liste usw. reduziert.; diese sind nur aufgeladen zu Begehen, die Ladung, wie Sie passieren. Auch ist Commit Charge oder Commit Limit nicht von Video-RAM oder sogar Video-RAM - "Fenster" - Größe betroffen.

Teste es selbst

Sie können all dies mit dem Testlimit-Tool von der SysInternals-Site aus demonstrieren. Option-m wird festgeschriebenen Adressraum zuweisen, aber nicht "touch" es, so wird nicht Zuweisung von RAM verursachen. Während option-d die Seiten zuweist und auch referenziert, wodurch sowohl die Commit-Gebühr erhöht als auch der verfügbare RAM verringert wird.

Referenzen

Windows Internals von Russinovich, Solomon und Ionescu. Es gibt sogar Demonstrationen, mit denen Sie alle diese Punkte mit dem Testlimit-Tool nachweisen können. Ich muss Sie jedoch warnen, wenn Sie denken, dass dies lang war, seien Sie gewarnt: Das Mm-Kapitel allein ist 200 Seiten; Das Obige ist ein EXTREM vereinfachten version. (Bitte beachten Sie auch den Abschnitt "Danksagungen" in der Einleitung.)

Siehe auch MSDN virtualalalloc Dokumentation

Vielleicht um die brillant akzeptierte Antwort zu addieren:

Windows und die meisten Programme gehen davon aus, dass sie so viel (virtuellen) Speicher wie nötig festschreiben können. Dies ist einer der Hauptgründe, warum man die Auslagerungsdatei nicht deaktivieren sollte, siehe vorgeschlagene Tatsache 2.2 in meine Superuser-Frage.

Ich verlinke auch auf diese brillante Serverfault-Antwort dort, was deutlich macht, wie die Auslagerungsdatei funktioniert:

Viele Leute scheinen davon auszugehen, dass Windows Daten pusht in die Seitendatei auf Anfrage. ZB: etwas will viel Speicher, und es gibt nicht genug RAM, um den Bedarf zu decken, so beginnt Windows wahnsinnig Schreiben von Daten aus dem RAM auf die Festplatte in dieser letzten Minute,so dass es RAM für die neuen Anforderungen frei.

Dies ist falsch. Unter der Haube ist noch mehr los. Im Allgemeinen verwaltet Windows einen Backing Store, was bedeutet, dass alles, was sich im Speicher befindet, auch irgendwo auf der Festplatte angezeigt werden soll. Nun, wenn etwas kommt und verlangt viel Speicher, Windows kann RAM sehr schnell löschen, da diese Daten bereits auf der Festplatte sind und bereit sind, bei Bedarf wieder in den RAM geladen zu werden. Man kann also sagen, dass viel von dem, was in Pagefile ist, auch im RAM ist; Die Daten wurden präventiv in pagefile platziert, um neue Speicherzuweisungsanforderungen zu beschleunigen.

Weitere Informationen finden Sie hier