Performance: Die Basis im System

Speicherverwaltung

Auch bei der Speicherverwaltung hat man der Optimierung der Sperrsituationen ein hohes Gewicht gegeben. Sperren sind erforderlich, weil Informationen über die genutzten Speicherseiten im System verwaltet werden müssen. Die Informationen über die genutzten Speicherseiten werden in einer als PFN (Page Frame) bezeichneten Datenbank gehalten. Über einen Spinlock wird sichergestellt, dass nur ein Prozessor zu einem Zeitpunkt Änderungen in dieser Datenbank vornehmen kann. Das betrifft viele Operationen wie

  • Mappings von virtuellen Adressen und Benutzeradressen,

  • Behandlung von Seitenfehlern und

  • Seitensperren für direkte Speicherzugriffe.

Die wichtigste Maßnahme zur Reduktion der Spinlock-Situationen betrifft die Verringerung der Fälle, in denen überhaupt Sperren angefordert werden. So weit wie möglich werden Änderungen an der PFN auch zusammengefasst, um mehrere Operationen mit nur einer Sperre ausführen zu können. Außerdem wird in vielen Situationen mit den Interlocked Operations gearbeitet, die – wie oben beschrieben – deutlich performanter sind. Das ist beispielsweise bei den Sperren für AWE (Address Windows Extensions) der Fall. Mit diesen Maßnahmen hat es Microsoft nach eigenen Angaben erreicht, mit nur noch 5% der bisher erforderlichen Sperren auf einem 32-Prozessor-System auszukommen. Bei Systemen mit wenigen Prozessoren fällt die Reduktion natürlich deutlich niedriger aus.

Sperren für den Systemspeicher bei Ein- und Ausgabeoperationen, die bei Windows 2000 noch genutzt wurden, gibt es überhaupt nicht mehr. Die hier verwendeten Warteschlangen kommen ohne Sperren aus.

Auch in anderen Bereichen wie dem Umgang mit zugesicherten Speicherseiten und den AWE wird nun nicht mehr mit Spinlocks gearbeitet.

Der Performance ist auch das optimierte Zurücksetzen von Speicherbereichen (Zeroing) zuträglich. Sowohl beim Starten des Systems als auch beim Neustart von Anwendungen werden Speicherbereiche auf den Wert null gesetzt, um Sicherheitsrisiken zu minimieren. Bisher wurde diese Aufgabe von einem Thread für das Gesamtsystem übernommen. Beim Windows Server 2003 ist dagegen ein Thread pro Prozessor beim Boot und ein Pool von Threads beim Neustart von Anwendungen dafür verantwortlich.

Neu ist auch, dass größere Seiten auch im User Mode genutzt werden können. Die Standardseitengröße liegt bei 4 KByte. Das ist bei Systemen mit mehreren Gbyte-Hauptspeichern nicht sonderlich groß und führt zu sehr großen Seitentabellen, in denen die genutzten Seiten verwaltet werden müssen. Bei Windows 2000 können vom System bereits größere Seiten genutzt werden. Beim Windows Server 2003 gibt es für Anwendungen die User Mode Large Pages, die 4 MByte groß sind. Entsprechend ist der Verwaltungsaufwand bei Anwendungen, die sehr viel Speicher benötigen, um einiges geringer.

Auch ist die maximale Größe von kritischen Systemressourcen deutlich gestiegen. So können größere Pools für Auslagerungs- und Nichtauslagerungsseiten und ein größerer Cache für das Dateisystem verwaltet werden. Die dynamische Aufteilung dieser Ressourcen wurde ebenfalls optimiert. Allerdings fehlen weiterhin Funktionen, mit denen man die Aufteilung anpassen kann.

Neben diesen größeren Anpassungen gibt es noch mehrere kleinere Optimierungen, die in der Summe aber zu der höheren Performance vor allem bei hoch skalierbaren Systemen beitragen:

  • Die Pools für die Verwaltung von I/O-Anwendungen pro Prozessor wurden optimiert, so dass weniger Anforderungen global auf Systemebene verwaltet werden müssen.

  • Die Verwaltung von so genannten Lookaside-Listen, in denen häufig verwendete Routinen verwaltet werden, wurde verbessert. Diese Listen wurden bei Windows 2000 sehr häufig analysiert und optimiert. Beim Windows Server 2003 geschieht das seltener, um nicht zu viel Last mit der Optimierung zu verbrauchen und damit im Ergebnis suboptimal zu arbeiten.

  • Auch bei Mehrprozessorsystemen erfolgt nun die Optimierung des Speichers auf Annahmen über die zukünftigen Anforderungen, und nicht mehr auf Basis von aufgetretenen Seitenfehlern. Es wurde also von einem reaktiven auf einen proaktiven Mechanismus umgestellt. Damit wird die Zahl der Seitenfehler potenziell verringert. Bisher fand man diesen Mechanismus nur bei der Nutzung mit Einprozessorsystemen.

  • Die Zahl der IRQL-Operationen wurde auch beim Speichermanagement verringert.