Andreas Stiller, Ingo T. Storm

Viel Wind um nichts

Speicheroptimierung unter Windows XP

Im Internet und auf Papier liest man ständig von irgendwelchen Tweaks, die unter Windows mehr Speicher zur Verfügung stellen: vom hochgeheimen Registry-Eintrag über simple VB-Skripte bis zur kommerziellen Speicher-Optimierungs-Software.

Unterthema: Alles muss raus!
Unterthema: Messergebnisse im Überblick

Speicher ist schon knapp, seit es ihn gibt. Auch wenn es unter Windows XP klemmt, weil nicht genug Speicher vorhanden ist, liegt es eher selten an Fehlern oder Versäumnissen seitens Windows, deren schädliche Auswirkungen sich durch irgendwelche Tricks vermeiden lassen. Schuld sind mehrere andere Faktoren: So kann Windows XP einfach mehr als zum Beispiel Windows 3.1, das noch auf einem 386er mit 2 MByte RAM ordentlich lief. Jede neue Funktion, jeder Komfort, den man heute erwartet, kostet nicht nur Rechenzeit, sondern auch Platz.

Das Gleiche gilt für Windows-Anwendungen. Assistenten, WYSIWIG und Interoperabilitäts-Verrenkungen wie Rechtschreib-Korrektur in der Tabellenkalkulation gibts nicht für eine Hand voll Bytes. Außerdem sind die zu bearbeitenden Datenvolumina über die Jahre geradezu explodiert. Natürlich war es relativ leicht, einen schlanken Bildschirmschoner für eine Grafikausgabe mit 16 Farben und 640 x 480 Pixeln zu schreiben. Heute belegt ein einziges Bild aus einer 5-Megapixel-Kamera im Speicher des Bildbearbeitungsprogramms über 14 MByte - von mehrstufigen Undo/Redo-Puffern und verschiedenen Bildebenen bei der Bearbeitung ganz zu schweigen.

Mit dem Arbeitsspeicher verhält es sich daher letztlich wie mit Ablageflächen in Büro und Wohnung: Jeder vorhandene Platz wird nach einer gewissen Zeit knapp. Es gibt also genug Gründe, Windows beim Aufräumen helfen zu wollen. Speicherverwaltung ist eine der traditionellen Kernaufgaben eines jeden (PC-)Betriebssystems. Unter DOS im Real Mode des Prozessors war sie noch recht übersichtlich, mit dem Protected Mode (Windows 3.1) wurde es schon etwas komplizierter und mit dem virtuellen Memory Management, wie es der 386-Prozessor einführte, geriet es spätestens ab Windows NT doch ziemlich unübersichtlich.

Jeder Prozess läuft zunächst einmal in seinem eigenen virtuellen, 4 GByte großen Adressraum, der erst zur Laufzeit auf den physischen abgebildet wird. Von diesen 4 GByte kann der Prozess sich in den unteren 2 GByte austoben, während der Kernel für jeden Prozess in die oberen 2 GByte eingeblendet wird (zu den Ausnahmen später mehr). Des Weiteren vermag Windows (wie alle modernen Betriebssysteme) trickreich den physischen Hauptspeicher mit Hilfe von Auslagerungsdateien virtuell zu vergrößern. Die übliche Verwaltungseinheit ist dabei eine so genannte Speicherseite von 4 KByte.

Kein Programm benötigt aber während seiner gesamten Laufzeit Zugriff auf den gesamten ihm zugeteilten Speicher. Windows gewährt daher jedem Prozess nur einen "Arbeitsbereich" von wirklich nötigen Seiten, den Working Set.

Bedarfsermittlung

Ein besonderer Working Set ist der System Working Set, der sich aus Teilen des Kernels und von Treibern sowie dem Speichervorrat des Cache-Managers zusammensetzt. Auch wenn Windows diesem Set ein paar Extrawürste brät, behandelt es ihn im Prinzip wie die herkömmlichen Working Sets. Immerhin kann man hier mit einigen Registry-Einträgen Einfluss ausüben.

Wenn ein Prozess auf mehr Speicher zugreift, als in seinen Working Set passt, wird der erst einmal vergrößert. Bei einer je nach Windows-Version unterschiedlichen Obergrenze oder wenn es im gesamten RAM eng wird, muss aber jeder Prozess auch Seiten wieder herausrücken und sein Working Set schrumpft.

Den "verfügbaren Speicher" (grün) verwaltet der Windows-Speichermanager in vier verschiedenen Listen - und nur zwei davon enthalten wirklich freie Speicherseiten.

Die einem Prozess entzogenen, aber veränderten Seiten vermerkt der Speichermanager in der Modified List. Von dort aus verewigt der Modified Page Writer sie auf der Festplatte. Anschließend landen die Seiten auf der Standby List - für den Fall, dass der Prozess später noch einmal auf dieselbe Seite zugreift. Für andere Prozesse werden Seiten auf der Standby-Liste erst herangezogen, wenn die beiden folgenden Listen leer sind: Die Free List enthält die noch freien beziehungsweise wieder freigegebene Seiten. Damit ein Prozess nicht in Speicherresten anderer Prozesse schnüffeln kann, füllt der Speichermanager die Seiten vor der Zuteilung mit Nullen. In Zeiten großer CPU-Langeweile macht das der Zero Page Thread auch vorbeugend. Er trägt abgearbeitete Seiten in die Zeroed Page List ein.

Nur bricht die Performance kräftig ein, wenn eben noch ungenutzte Speicherseiten von der Festplatte zurückgeholt werden müssen, weil Windows einen Anlass hatte, den Working Set zu verkleinern. In manchen Fällen, etwa bei Echtzeitanforderungen wie bei der Telefonie oder Video-Dekodierung, sind ausgelagerte Speicherseiten nicht nur lästig, sondern eine mittlere Katastrophe. Daher kann ein Programmierer für diese Fälle Speicherbereiche innerhalb des Kernelspeichers verriegeln (Nonpaged Pool), die somit immer im schnellen physischen Zugriff bleiben. Ansonsten gehören Seiten, die im Kernel-Modus angefordert werden, zum Paged Pool. Einige Seiten sind zusätzlich fest "verdrahtet", ohne in den Pools enthalten zu sein, etwa die Seitentabellen selbst.

Was der Taskmanager als "verfügbaren Speicher" bezeichnet, ist noch lange nicht "frei". Hierunter fallen auch Speicherbereiche, die der Speichermanager einem Prozess zwangsweise entzogen hat, obwohl der sie vielleicht schon bald wieder benötigt.

Der Taskmanager zeigt unter "verfügbar" übrigens die Summe aller genannten Listen von Free über Zeroed und Standby bis Modified an. "Verfügbar" heißt daher keineswegs "braucht sonst keiner", sondern unter Umständen "wurde gerade jemandem weggenommen". Dass Otto Normaluser Ersteres vermutet, nutzen die marktgängigen Programme zur Speicheroptimierung aus (siehe Kasten "Alles muss raus!"). Daher helfen diese Programme auch nur oberflächlich.

Stellschrauben

Wie Windows bei der Speicher-Zu- und -Umverteilung vorgeht, kann der Anwender nur in engen Grenzen beeinflussen. In den Systemeigenschaften gibt Microsoft dem XP-Benutzer unter "Erweitert/Systemleistung/Erweitert/Speichernutzung eine offensichtliche Möglichkeit, ein wenig zu experimentieren.

Hinter dem Punkt Speichernutzung verbirgt sich die Registry-Einstellung LargeSystemCache. Sie legt die Standardgröße des Filecaches fest und bestimmt auch, wann veränderte ("dirty") Seiten zur Festplatte zurückgeschrieben werden sollen. Unter XP ist LargeSystemCache normalerweise 0, was für 8 MByte Filecache steht. Etwa wenn die Hälfte des Cache belegt ist (bei noch 1000 freien Seiten), wird zurückgeschrieben. Steht hier eine "1" (Standard bei Windows Server 2003), darf fast der ganze physische Speicher - bis auf 4 MByte - für Filecaching benutzt werden. Und erst, wenn nur noch 250 Seiten frei sind, beginnt das Rückschreiben. Diese Einstellung ist definitiv nur für Server in großen Netzwerken sinnvoll, wo der Rechner hauptsächlich Dateien verwaltet.

Doch die meisten Allerweltstipps zum Windows-XP-Speicher beziehen sich nicht auf Menüpunkte, sondern direkt auf die Registry-Einträge des Speichermanagers in in HKLM/SYSTEM/Control/SessionManager/MemoryManager.

AlwaysUnloadDLL wurde schon von Windows 2000 ignoriert. In der englischen Fassung liest man daher auf support.microsoft.com: "Important: This registry key is no longer supported in Microsoft Windows 2000 or later" - allein die deutsche Fassung schweigt sich darüber aus, obwohl der Eintrag eine höhere Revisionsnummer trägt als das Original.

ClearPageFileAtShutdown dient allein der Datensicherheit. Im Pagefile könnten sensible Daten enthalten sein, die vielleicht nach dem Herunterfahren des Systems nicht auf der Platte verweilen, sondern mit Nullen überschrieben werden sollten. Wenn man es einschaltet, soll man sich aber nicht wundern, dass das Herunterfahren deutlich länger dauert.

Mit größter Vorsicht ist der Tipp zu genießen, DisablePagingExecutive auf "1" zu setzen. Damit soll das System daran gehindert werden, selten benutzte Teile von Kernel sowie Kernel-Treibern auszulagern. Doch unsere Messungen haben selbst bei 512 MByte Speicher ergeben, dass das wegen der zusätzlich belegten Seiten eher kontraproduktiv ist. Erst ab 1 GByte Speicher und mehr spielen die normalerweise wenigen MByte keine signifikante Rolle mehr, sodass man sie auch dauerhaft im Speicher halten kann - wo sie aber wegen des vielen Speichers ohnehin bleiben dürften.

Entlastungseingriff

Den Eintrag LargePageMinimum kennen viele Athlon-Besitzer vielleicht noch als Patch, um einen Prozessor-Bug zu umgehen. Dann musste man hier einen hohen Wert, etwa 0xffffff als "Disable", eintragen. Standardmäßig verwaltet XP erst ab einem Speicherausbau von 256 MByte ausgewählte Bereiche in größeren Speicherseiten von 4 MByte anstatt KByte. Das bedeutet erst einmal Speichereinbußen durch größeren "Verschnitt", dafür wird aber der Translation Lookaside Buffer (TLB), also die Umrecheneinheit von virtuellen in physische Adressen erheblich entlastet. Das kann durchaus spürbare Performance-Vorteile einbringen. Dieser Registry-Key ist bei XP üblicherweise nicht angelegt; das Experimentieren damit ist für Nicht-Athlon-Besitzer unschädlich. Die Performance-Veränderung hängt einerseits von den verwendeten Applikationen ab, aber auch entscheidend vom TLB und damit vom Prozessortyp.

Nur Programmierer in der Debugging-Phase beziehungsweise Support-Mitarbeiter in größter Not sollten sich an die [Non]PagedPoolSize/Quota wagen, also an die Größen der Pools für auslagerbaren und nicht auslagerbaren Systemspeicher. Wenn diese Pools zu klein sind, deutet das auf einen Design-Fehler in einer Applikation beziehungsweise einem Treiber hin.

Die insgesamt dem System zur Verfügung stehende Seitenanzahl bestimmt der Registrierungseintrag SystemPages. Maximal kann der virtuelle Systemspeicher unter XP 1,3 GByte umfassen. Auch an diesem Wert sollte man nur in Notfällen herumschrauben, etwa wenn das System mangels freier Speicherseiten in Panik gerät und beispielsweise

"Stop 0x0000003F or NO_MORE_SYSTEM_PTES" 

melden muss. Meist ist auch daran eine amoklaufende Applikation Schuld, die zu viel Kernelspeicher anfordert und nicht korrekt wieder freigibt. Um diese zu entlarven, reicht schon der Taskmanager oder besser der Process Explorer von Sysinternals [3]. Fachleute verwenden darüber hinaus den Kernel-Debugger sowie die Support-Tools [4] von Microsoft. Poolmon.exe beispielsweise ist sehr nützlich: Es überwacht sämtliche Speicheranforderungen und kann so helfen, fehlerhaften Allokationen oder Speicherlöchern (Memory leaks) auf die Schliche zu kommmen.

Den Eintrag PagingFiles sollte man nur in Ausnahmefällen direkt manipulieren; das vorgesehene Menü in System/Systemleistung/Erweitert/Virtueller Arbeitsspeicher tuts und fängt auch noch Fehler ab. Im Regelfall verwendet XP ein Pagefile, das minimal eineinhalbmal so groß ist, wie der physische Speicher und maximal dreimal so groß.

Der klassische Tipp ist, das File auf einer zweiten schnellen Platte einzurichten. Deren erste Partition wird dann zur dedizierten Pagefile-Partition erklärt, ähnlich wie bei Linux die Swap-Partition. Viel mehr als dreifache RAM-Größe (inklusive Ausbaureserve) ist aber nur dann sinnvoll, wenn man die XP-Option "Fast User Switching" weidlich nutzt. Der Rest der Platte lässt sich für andere Betriebssysteme oder selten benutzte Datenbestände oder Streaming-Dateien (Videos) einsetzen. Aber auch hier gilt: lieber 50 Euro in mehr RAM investieren als in eine zweite Platte nur für die Auslagerungsdatei.

SecondLevelDataCache ist auch so eine Leiche aus grauer PC-Urzeit, wo es NT für Prozessoren ohne CPUID (sowie für Mips, PowerPC und Alpha) gab, sodass der Kernel die Größe des L2-Caches nicht abfragen konnte. Dieser Eintrag ist bereits seit dem Pentium II obsolet. Er wird folgerichtig von XP völlig ignoriert.

Eine Sonderstellung genießt der Eintrag PhysicalAddressExtension. Er ist kein Tuning-Schalter, sondern eine versteckte Anzeige. Falls er auf "1" steht, arbeitet das System mit der Physical Address Extension PAE. Mit PAE vermögen die besseren Serverversionen von Windows auf Speicher jenseits der 4 GByte zuzugreifen, und zwar mittels einer Speicherfenstertechnik (wie damals bei EMS unter DOS). Ältere Prozessoren kommen so über 36 Adressleitungen an bis zu 64 GByte physischen Speicher heran, neuere wie Athlon64/Opteron und jetzt auch Pentium 4 haben derer 40 für bis zu 1 TByte. Die 32-bittigen Windows-Server nutzen davon je nach Edition zwischen 4 GByte bis zu 64 GByte. XP ist wie Windows Server 2003 (Standard) auf 4 GByte beschränkt, erlaubt User-Prozessen jedoch, sich in 3 anstatt 2 GB breit zu machen.

Windows XP Service Pack 2 stellt dieses Feature trotzdem auch den Home- und Pro-Besitzern zur Verfügung, da es Voraussetzung für die Nutzung des NoExecute-Bit moderner Prozessoren ist. Athlon 64 und Pentium 4 mit EMT64 bieten so rudimentären Schutz gegen Buffer-Overflow-Attacken. Der PAE-Kernel arbeitet mit größeren Seitentabellen, die mehr Platz belegen. Außerdem bekommt die Seitenverwaltung eine zusätzliche Ebene, was die Performance theoretisch minimal verlangsamt - wir haben nichts Auffälliges feststellen können. Sollte die bei den Pagepools zitierte oder eine ähnliche Fehlermeldung auftauchen, wäre ein Verzicht auf PAE und damit des NoExecute eine erste Notmaßnahme, da dann mehr Seiteneinträge zur Verfügung stehen.

Letztlich gilt auch bei Speicherknappheit unter Windows XP die alte Weisheit: "Echtes RAM ist durch nichts zu ersetzen." Wer die eigene Zeit am Rechner mal in Arbeitszeit und somit Kosten umrechnet, sieht im RAM-Kauf die preiswerteste Lösung. Nur da, wo Ausbaureserven technisch oder finanziell verbaut sind, lohnt sich das eine oder andere Experiment. Die Stellschrauben im Windows-Memory-Management sind entweder überholt oder auf spezielle Einsatz-Szenarien abgestimmt. Und oh Wunder: die Speicher-Tuning-Programme sind in den letzten zehn Jahren nicht wesentlich besser geworden. (as)

Literatur

[1] Mark E. Russinovich, David A. Solomon, Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 (Pro-Developer)

[2] ClearMem und weitere Tools: www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/reskt4u4/rku4list.mspx

[3] Process Explorer, www.sysinternals.com

[4] Windows XP SP2 Support Tools: www.microsoft.com/downloads/details.aspx?FamilyID=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en

[5] Ingo T. Storm, Christian Persson, Placebo forte! Was wirklich hinter SoftRAM 95 steckt, c't 12/95, S. 100

Kasten 1

Alles muss raus!

Wenn schon die meisten kostenlosen Tipps nicht helfen - wie stehts denn mit den kommerziellen Tuning-Programmen? Nun, ganz so unverfroren wie SoftRAM 95 [5] sind heutige Speicheroptimierer nicht. Doch sie pfuschen dem Windows-Speichermanagement ins Handwerk, bestenfalls bieten sie ein paar triviale Handreichungen an. Die gründlichste Analyse dieses Phänomens stammt vom Sysinternals-Crack Mark Russinovich und wurde an mehreren Stellen veröffentlicht, unter anderem im Band "Microsoft Windows Internals" der technischen Referenz zum Windows Server 2003 [1].

Speicheroptimierer machen sich im Speicher sehr breit und dann wieder dünne. Dadurch werden die Working Sets anderer Programme beschnitten. Der Effekt hält leider höchstens so lange an, wie die anderen Programme nichts zu tun haben.

Die Speicheroptimierer gehen normalerweise in drei Schritten vor: Erstens ganz viel Speicher anfordern, zweitens kurz drin herumrühren und drittens freigeben. Ob das auf Mausklick oder regelmäßig im Hintergrund passiert, ist Wurst - der Effekt ist immer derselbe: Die kurzfristige Speicherverknappung führt dazu, dass der Windows-Speichermanager die Working Sets anderer Programme beschneidet. Anschließend wird im Taskmanager mehr Speicher als "verfügbar" angezeigt. Aber spätestens, wenn die verdrängten Programme wieder etwas tun haben, holen sie sich ihren ursprünglichen Working Set zurück.

Lediglich zu Debugging-Zwecken ist so eine Zwangsräumung manchmal sinnvoll. Daher gibt es auch von Microsoft ein kostenloses Tool namens ClearMem [2] aus dem NT Server Resource Kit. Letztlich gilt: Wenn eine Applikation wirklich viel Speicher benötigt, wird er ihr auch ohne Memory-Optimierer zugestanden.

Auch das zweite oft gemachte Versprechen erfüllen diese Programme nicht: Speicher zurückgewinnen, der durch Schlamperei anderer Programmierer verloren ging. Die einfache Erklärung lautet, dass es von außen gar nicht feststellbar ist, ob ein Prozess ein Speicherleck hat oder ob er den Speicher vielleicht doch noch benötigt. Außerdem versucht Windows ja schon im Sekundentakt, die Working Sets aller Programme zu verkleinern. Wenn ein Programm Teile des ihm zugesicherten Speichers nicht benutzt, werden die also nach einiger Zeit ohnehin ausgelagert.

An immerhin einer Stelle sparen manche Speicheroptimierer wirklich RAM ein. Sie werfen Daten aus der Windows-Zwischenablage, die nach Beendigung eines anderen Programms dort verblieben sind. Alternativ kann man natürlich auch einfach an beliebiger Stelle ein Zeichen markieren und Strg-C drücken ...

Kasten 2

Messergebnisse im Überblick