[*]Auslagerungsdatei verlagern
[...]
Das liegt einfach daran das ein 32-Bit-Programm von seinen 4GB virtuellem Speicher sowieso nur 1,8GB physikalisch nutzen kann, braucht es mehr geht dieser Teil in die Swapdatei.
Warum sollte das so sein?
Ein 32-Bit Programm im 32-Bit Windows OS hat maximal 2GB virtuellen Speicher. Mit dem Linker flag /LARGEADDRESSAWARE übersetzt, kann es 3GB virtuellen Speicher nutzen, wenn auch noch der /3GB Bootswitch (bzw. increaseuserva in BCDEDIT) mitspielt.
Wer aber die Auslagerungsdatei deaktivieren möchte, hat im Moment vermutlich eh >4GB. Sprich, wenn es ein Windows OS ist, hat er eine 64-Bit Version wie z.B. Vista 64-Bit. Dort hat jede Anwendung mit obigem Compileswitch dann
4 GB:
http://msdn.microsoft.com/en-us/library/aa366778.aspx
Wieviel Virtueller Adresspeicher von einer Anwendung adressiert werden kann (s.o. 2-4GB) hat natürlich nichts damit zu tun welche 4k Pages davon im Physikalischen Speicher liegen und welche im Swapfile. Vielmehr ist das Sache des Betriebssystem hier nach Zugriffsmustern zu entscheiden welche Pages ins Swapfile kommen und welche nicht. Dies im
Gleichgewicht mit konkurrierenden Diensten wie z.B. Windows Datenträgercache und Superfetch, die prinzipiell so viel physikalischen Speicher haben wollen wie sie kriegen können.
Woher die 1,8GB Einschränkung kommen soll ist mir schleierhaft. Im Microsoft Jargon heißt die Menge an pages, die im physikalischen Speicher liegen, und einem Prozess gehören das
Working Set. Ich kenne solche Einschränkungen nicht für das Working Set. Darüberhinaus gibt es auch eine API gibt um noch schneller und einfacher Speicher jenseits der 2GB anzusprechen (AWE) und explizit physikalischen Speicher (non-paged) zu fordern:
http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Somit ist es ein leichtes für Anwendungen >1,8GB physikalisch anzusprechen.
--
Die Auslagerungsdatei zu deaktivieren ist möglicherweise auch bei 8GB Hauptspeicher nicht die beste Idee. Manche Anwendungen gehen verschwenderisch mit Hauptspeicher um (*), da ist es günstiger die Seiten wegzupagen u. den physikalischen Speicher für sinnvollere Dinge zu verwenden (und wenn es Superfetch ist). Angeblich soll sich Photoshop auch beschweren, wenn die Auslagerungsdatei deaktiviert ist.
Ich stimme also zu, dass das Auslagerungsdatei deaktivieren nicht unbedingt gut ist. Die Begründung mit den 1,8GB höre ich hingegen zum ersten Mal u. hätte gerne einen Link zum Nachlesen zu dem Thema. Auch wenn's Offtopic ist.
(*) entweder weil sie zu viel Speicher vorausschauend allokieren, ihn aber nicht nutzen. Oder aufgrund von Speicherleaks, die in C(++) schnell auftreten können wenn nicht sorgfältig analysiert und bei größeren Projekten Toolgestützt überprüft.
ca 920MB sind im Moment voll auf der RAMDisk
Ich glaube fast ja, ich bringe dauernd durcheinander wie das alles zusammenhängt... und bringt es etwas, die Clustergröße auf die Größe eines erasable Blocks zu setzen?
