DerFisch.de

Im zweiten Teil geht es um das RAM Tuning, welches ja auch oft wahre Wunderdinge verspricht. Mehr freier Speicher für Anwendungen, schnellere Zugriffe, weniger Abstürze.

7. Kernel Auslagerung abschalten.
Der Eintrag in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management-->DisablePagingExecutive soll verhindern, dass Kernel Dateien auf die Platte ausgelagert werden und stattdessen ständig im RAM gehalten werden. Dummerweise handelt es sich bei dem Eintrag aber um einen Legacy Key, der seit NT4 SP3 nur noch aus Kompatibilitätsgründen in der Registry zu finden ist und der ansonsten genau gar keine Wirkung hat, wovon man sich mit einem Blick in den Taskmanger-->Systemleistung-->Kernel Speicher selber überzeugen kann. Egal, ob der Wert gesetzt ist oder nicht, es wird auf jeden Fall ausgelagert. Unter W2K ohne SP4 konnte es bei gesetztem Key sogar zum Abstürzen kommen, falls ein Treiber nicht sauber programmiert war. The DisablePagingExecutive Setting May Cause Windows 2000 to Hang)

8. Nicht benötigte DLL Dateien aus Speicher entfernen.
HKLM\SOFTWARE\Microsoft\ Windows\CurrentVersion\Explorer --> AlwaysUnloadDLL soll bewirken, dass beim Beenden eines Programms nicht mehr benötigte Dateien aus dem Speicher entfernt werden. Tut er bestimmt auch, jedenfalls wie Windows NT. Bei Windows 2000 und XP ist der Key wirklungslos, wie auch in einem Technet Artikel nachzulesen ist: Debugging with the Shell. Der wichtigste Satz daraus lautet: „For operating systems prior to Windows 2000, you can shorten the inactive period by adding the following information to the registry”. Ein schneller Test bestätigt auch, dass nach dem Setzen des Key auf keinen Fall mehr Speicher nach dem beenden eines Programms zur Verfügung steht als vorher.

9. System Cache beeinflussen.
Zwei Veränderungen im Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, nämlich „LargeSystemCache“ und „IOPageLockLimit“ beeinflussen das Caching Verhalten von XP. Tun sie auch und kann sogar sinnvoll sein. Zumindest dann, wenn man einen Fileserver betreibt. Die Empfehlung, bei einer Workstation LargeSystemCache auf 2 und Size auf 3 zu setzen, führt zusammen mit der Veränderung des IOPageLockLimit dazu, dass das System mehr Speicher für Dateisystemoperationen reserviert. Dieser Speicher fehlt dann aber den Anwendungen. Ergebnis: Es wird mehr ausgelagert, das System wird langsamer. Details dazu finden sich z.B. in der Dokumentation zum W2K Ressource Kit Registry Reference LargeSystemCache“ Zitat: „Increasing the size of the file system cache generally improves server performance, but it reduces the physical memory space available to applications and services. Similarly, writing system data less frequently minimizes use of the disk subsystem, but the changed pages occupy memory that might otherwise be used by applications.”

10. System Page Table Entries erhöhen
Im bereits genannten Registry Key findet sich auch ein Eintrag namens SystemPages. Manche Quellen empfehlen, dort den Wert 0xFFFFFFFF einzutragen, was Windows anweist, das Maximum an PTEs innerhalb des verfügbaren Arbeitsspeichers anzulegen. Dadurch sollen bei großen Datei- und Speicheroperationen Abstürze vermieden werden. Davon mal abgesehen, dass ich bei XP noch nie abstürze bei solchen Vorgängen hatte, obwohl ich den Key nicht verändert habe, verweise ich wieder auf die MS Dokumentation: Registry Reference System Pages. Zitat: “Caution. Do not change the value of this entry. Changing it prevents the system from calculating an optimal value for your system and adjusting the value when your system changes”. Es ist also bestenfalls nutzlos, diesen Wert zu verändern.

11. Speicher aufräumen und defragmentieren.
Das ist einer meiner absoluten Lieblingstipps. Es klingt ja auch logisch und nachvollziehbar. Viel freies RAM ist gut und wenn es am Stück vorliegt, ist es noch besser. Schließlich will man ja sein Bier auch lieber aus dem Maßkrug anstatt aus 50 verteilten Schnapsgläsern genießen. Und so, wie man Festplatten defragmentiert, geht das bestimmt auch mir dem RAM. Dafür bastelt man sich eine VBS Datei mit einer einzigen Zeile „Mystring = (160000000)“. Um Speicher frei zu räumen, legt man sich ebenfalls eine VBS Datei mit der Zeile „FreeMem = Space(32000000)“ an. Was passiert nun bei Ausführung dieser beiden Dateien? Nichts. Weder wird mir im Taskmanager mehr RAM freies RAM angezeigt noch wird irgendetwas schneller. Wie denn auch? Das erste Visual Basic Script versucht, im RAM eine Variable von 160 MB Größe anzulegen, die dann sofort wieder beim Beenden des Programms gelöscht wird. Das zweite füllt eine Variable namens FreeMem mit einem String von 32 MB Grösse, die ebenfalls sofort wieder gelöscht wird. Was ist die Absicht dahinter? Sehr grob vereinfacht dies: Es wird möglichst viel Speicher belegt. Der Speichermanager teilt diesen auch zu. Zu Lasten anderer Programme, deren bisher genutzte Speicherseiten jetzt aus dem RAM in den Cache oder im Extremfall sogar in die Auslagerungsdatei verschoben werden. Will man also jetzt mit diesen Programmen weiterarbeiten, werden sie langsamer sein als vorher, weil erst die Daten vom Swap- in den Arbeitsspeicher geladen werden müssen. Dazu kommt, das diese „Aufräumaktionen“ völlig überflüssig sind, da der Speichermanager von Windows die Verwaltung weitaus effektiver vornimmt. Mark Russinovich, der Betreiber von Sysinternals und Autor im Windows 2000 Magazin hat in selbigem einen Artikel unter der Überschrift Schlangenöl für den Speicher veröffentlicht, den ich jedem nur empfehlen kann.