« _x003C_none_x003E
Projektdateien im Projektmappen-Explorer sortieren »

Large Pages

Wie ich bereits vor einiger Zeit berichtet habe, gab es einige interessante Informationen von Bob Ward zum Recht "Lock Pages In Memory" und dessen Auswirkungen auf die Auslagerung von Speicher. Nun kommt noch eine Ergänzung im Hinblick auf die interne Speicherverwaltung.

Falls die folgenden drei Bedingungen zutreffen, hat das Recht auch noch eine weitere Konsequenz:

  • SQL Server Enterprise Edition
  • Der Computer muss wenigstens 8GB physischen Speicher (RAM) haben
  • Das Recht "Lock Pages in Memory" ist für das Konto gesetzt, unter dem der SQL Server läuft.

Die Konsequenzen werden in einem weiteren Artikel von Bob Ward beschrieben, den ich im folgenden nur kurz anreissen möchte.

Was sind nun Large Pages?

Grundsätzlich geht es erst einmal darum, Seiten in einer größeren Seitengröße zu verwenden, als sie vom Betriebssystem organisiert werden. Der Vorteil ist, dass der Prozess der virtuellen Adressübersetzung (virtual address translation) normalerweise schneller wird. Die normale Seitengröße für Windows-Speicher beträgt 4Kb bei x64 Systemen. Aber mit "Large Pages" ist die Größe 2Mb.

Falls alle Bedingungen erfüllt sind, findet man im Errorlog des Servers nach einem Neustart die folgenden Zeilen:

Large Page Extensions enabled. 
Large Page Granularity: 2097152 
Large Page Allocated: 32MB

Falls es nicht aktiviert ist, steht dort:

Cannot use Large Page Extensions:  lock memory privilege was not granted.

Wie jetzt der Speicher verwendet wird, kann man über eine DMV ermitteln:

select large_page_allocations_kb, locked_page_allocations_kb from sys.dm_os_process_memory;

Der erste Wert gibt die Größe der Large Pages an, die zweite Zahl die Größe der gesperrten Seiten (locked pages aus dem Buffer Pool), welche auf Grund des Rechtes "Lock Pages in Memory" vor direkten Zugriffen des Betriebssystems geschützt werden.

Die Large Pages werden nicht für den Buffer Pool verwendet, sondern für interne Strukturen wie "lock management" und "buffer hash". Will man so etwas auch für den Buffer Pool, muss man das Trace Flag 834 setzen. Dies sollte aber erst nach reichlicher Überlegung und Analyse erfolgen.

Trace Flag 834

Das zweite Szenario betrifft das Trace Flag 834. Wird dieses gesetzt, versucht der SQL Server beim Neustart auf einen Schlag sämtlichen Speicher (max server memory) in Large Pages zu allokieren. Was dies bedeutet, insbesondere für die Startzeit eines Systems liest man am besten im Artikel von Bob nach.

64-bit, administration, memory, trace flag
SQL Server
 Print article This entry was posted by cmu on 10.09.10 at 11:19:55 . Follow any responses to this post through RSS 2.0.