Dir ist aber klar, das im RAM ständig Daten hin und her geschoben werden, bzw Ressourcen angefordert und wieder freigegeben werden. Je voller der Ram ist, desto weniger/schwerer wird es passende Stellen zu finden um die Daten hin zu packen. Das nennt sich äußere Datenfragmentierung. Nicht zu verwechseln mit der inneren Datenfragmentierung, die mit der Pagesize zu tun hat.
Wenn du also 90% Ram-Auslastung hast, und dein maximal am Stück freier Speicherbereich 50MB sind, und du 51 MB brauchst, dann fängt dein PC FREUDIG an zoch MB oder GB hin und her zu schieben, damit er am Stück 51MB frei hat. Je nachdem wie groß die einzelnen Speicherbereiche die reserviert wurden eben sind.
Da verpufft dir extrem viel Leistung.
Daher ist es besser so ca 70-80 Speicherauslastung zu haben und bei dauerhaft mehr lieber den Ram aufzustocken, denn das hin und her geschiebe kostet extrem viel Performance.
@Kaktus, klar das Win7 recht spät erst anfängt auszulagern das ist auch gut so

Bei Vista ist es meines Wissens aber genau umgekehrt. Das fängt verdammt früh an schon Sachen auszulagern.
Wenn man zich kleine Programme etc auf hat, die nicht Laufzeit kritisch sind, ist es auch kein Problem, wenn da mal was ausgelagert werden muss.
Sind aber 3 Programme oder 4 da, die man wirklich effektiv nutzt und da wird angefangen auszulagern, machts keinen spaß mehr.
Ich denke ich muss deine phantasievolle Sichtweise vom Speichermanagement , ins Licht der Wirklichkeit holen. Es ist tatsächlich leider sehr viel komplexer und es gibt auch nicht nur einen Speicher Pool in dem man soeben mal alles reinwirft und dann wieder rausholt. Es werden virtuell verschiedene Schichten in abstrakter Form verwendet. Wenn du z.b. eine Anwendung startest, dann gibt ihr der Speichermanager zuerst 0000000016-7FFFFFFF16 Rahmen frei. Sobald die Anwendung sich nun im Speicher befindet ermittelt der Speichermanager welche Speicherseiten nicht kritische Datenseiten und Codeseiten sind. kritische Inhalte, die im Speicher verbleiben sollen, müssen von der Anwendung gelocked werden. Die anderen Seiten gelten als auslagerbar. Falls nun Speicher physikalisch benötigt wird der grösser als der grösste freie zusammenhängende Speicherblock ist, werde solange nichtkritische Seiten auf die Platte geswaped, bis ein zusammenhängender Frame der benötigten Menge frei geworden ist. Das ist gleichzeitig auch der grösste Nachteil dieses Systems. Falls kein zusammenhängender Frame mehr möglich ist, nachdem auch alle kritischen nicht gelockten Seiten aus dem Speicher sind, wird der Block in Fragmente zerlegt.
Jetzt gibt es noch die Möglichkeit, nochmals Speicher als eine neue abstrakte virtuelle Speicher Schicht mit dynamischer Grösse, paralell zum virtuellen Speicher anzulegen.
Ein Beispiel hierfür ist der SystemFileCache. Hier wird automatisch der ganze Speicher minus kritischer Seiten, dynamisch als Systemfilecache verwendet. Im Zweifelsfall haben kritische Frames Priorität. Üblicherweise arbeitet jedes Speichermanagement nach der FiFo(first in first out) - Regel, die bei jeglicher Art von virtualisierten Speicher angewendet wird.
Der Vorteile des virtuellen Speichers liegt auf der Hand. Es ist praktisch möglich einer Anwendung vorzugaukeln, dass immer genug Speicher vorhanden ist, selbst wenn der ph. Speicher < = von der Anwendung gefordert ist.
Zum Anhang, Bild 2.
Erklärung:
virtueller Speicher = von der Anwendung reservierter Speicher
commited Speicher = von der Anwendung tatsächlich belegter Speicher
belegter Speicher(WorkingSet) = von der Anwendung belegt und geschützter Speicher.
privater Speicher(PageFile) = auslagerbarer Speicherseiten Stapel der Anwendung(reservierte, freie, allozierte und geschützte Seiten)
Der Trick um Windows davon abzuhalten ständig Seiten auszulagern, ist der Systemfilecache. Damit lagert Win zwar auch aus aber nur vom 1. Speicher zum 2. Speicher. Das FiFo System besorgt den Rest. Nach einer gewissen Zeit pendelt sich der Speicher optimal für fie Anwendung ein. Es bleibt genau das im Speicher was am meisten verwendet wird und die Grösse des Caches ist der ph. Speicher minus virtueller Speicher der Anwendung.
In dem Fall hier
Virtueller Speicher Anwendung: 1,4gb davon 1,4gb im ph. Speicher davon 800mb im Filecache und 600mb im v. Speicher
Auslagerung System gesamt: 3,6gb davon in Verwendung 320mb
HD Zugriffe der Anwendung gesamt: lesen 1,1tb / schreiben 188mb.
SystemFileCache : 2,6gb(800mb Anwendung + 500mb Texturen + paar MB system. Rest = frei)
Ich hab 16 Std GTA IV ruckelfrei und ohne ständige Nachladeaussetzer, gezockt. Die gesamte erste Stadt ist quasi mit 1,4gig voll bedient. Rechnet man noch die benötigten 500mb Texturen dazu(siehe Pic 1) reichen selbst 3gb um gta iv in unten zu sehender Res. mit 512mb Graka, komplett in den Speicher zu quetschen.
Wie alles hat natürlich auch der Filecache(auch Dirty Write Back Cache genannt) seine Nachteile. Nicht für sensitive Daten geeignet weil, eine nicht vorherbare Zeitspanne vergeht, bevor Daten tatsächlich geschrieben(nur @idle) werden und weil bei schreiben in den Cache keine Validierung(mögliche Fehler werden mitgeschleppt) durchgeführt wird. Ich hab das erst einmal bemerkt indem eine vom Cache verschleppte Textur plötzlich versaut war. Ohne Neustart bringt man das nicht mehr raus. Fürn priv. Einsatz aber vollauf tauglich.