Vergrößern und Verkleinern des Pufferpools unter NUMA
Dieses Thema beschreibt das Zuweisen von Arbeitsspeicherseiten aus dem Pufferpool, wenn nicht einheitlicher Speicherzugriff (Non-Uniform Memory Access, NUMA) verwendet wird. Verwenden Sie diese Informationen, um die Verwendung von NUMA in SQL Server und die Interpretation der Leistungsindikatoren des Buffer Node-Objekts zu verstehen.
Verteilung von Arbeitsspeicher
Für jeden physischen NUMA-Knoten ist ein SQL Server-Speicherknoten vorhanden. Die Speicherknoten wachsen unabhängig voneinander, teilen den Speicher jedoch gleichmäßig auf. Um die Verteilung von lokalem Arbeitsspeicher und Fremdarbeitsspeicher in SQL Server zu zeigen, wird in diesem Thema ein Beispiel verwendet, in dem davon ausgegangen wird, dass der Computer 16 Gigabyte (GB) Arbeitsspeicher aufweist. Andere Anwendungen, einschließlich Windows, haben einen Teil des Arbeitsspeichers von jedem Knoten beansprucht, SQL Server hat eine gewisse Menge Arbeitsspeicher für seine Prozesse außerhalb des Pufferpools zugewiesen, und SQL Server besitzt 10 GB Arbeitsspeicher zum Zuweisen zum Pufferpool. Der Pufferpoolspeicher wird aufgeteilt auf vier physische NUMA-Knoten, N0, N1, N2 und N3. Im Folgenden ist der verfügbare lokale Arbeitsspeicher für jeden dieser Knoten aufgeführt:
N0 – 1 GB
N1 – 3 GB
N2 – 3 GB
N3 – 3 GB
In der obigen Konfiguration erhalten und verwenden schließlich alle Knoten 2,5 GB Arbeitsspeicher. Knoten N0 wird jedoch am Ende 1,0 GB eigenen Arbeitsspeicher und 1,5 GB Speicher von anderen Knoten aufweisen.
Arbeitsspeicherzuweisung beim Start
Wenn NUMA verwendet wird, erhält SQL Server Arbeitsspeicher vom Betriebssystem mit einer Rate, die mit einem Nicht-NUMA-System vergleichbar ist, auch wenn der anfängliche freie Arbeitsspeicher ungleichmäßig auf die Knoten verteilt wird. Der Pufferpool versucht, möglichst viel lokalen Arbeitsspeicher für jeden Knoten zu erhalten, was jedoch schwierig ist, weil Windows zurzeit keine API zum Zuordnen von Arbeitsspeicher von einem bestimmten Knoten besitzt.
Während SQL Server Arbeitsspeicher zugewiesen wird, können Sie möglicherweise beobachten, dass einige Knoten viele Seiten von anderen NUMA-Knoten erhalten (so genannte Fremdseiten). Diese Seiten werden jedoch nicht beim Anlaufprozess verwendet, da sie häufig zum besitzenden Knoten übertragen werden können und für diesen Knoten lokal werden. Wenn der Wert von max server memory erreicht wird, haben manche Knoten möglicherweise Fremdarbeitsspeicher, sobald aber das Arbeitsspeicherziel erreicht ist, behandelt der Pufferpool lokalen Arbeitsspeicher und Fremdarbeitsspeicher gleich. Wenn beispielsweise nicht genügend Arbeitsspeicher verfügbar ist, versucht der Pufferpool nicht, Fremdspeicherseiten vor lokalen Speicherseiten freizugeben.
Beschränken des Arbeitsspeichers auf bestimmte Knoten
Wenn SQL Server für die Ausführung auf einer Teilmenge der verfügbaren NUMA-Knoten konfiguriert ist, wird der Pufferpool nicht automatisch auf den Arbeitsspeicher dieser Knoten beschränkt. Verwenden Sie in diesem Fall die Option max server memory, um den Pufferpool zu beschränken. Informationen zu max server memory finden Sie unter Serverarbeitsspeicher-Optionen.
Freigeben von Arbeitsspeicher von einem Knoten
Wenn NUMA verwendet wird, werden die Werte für max server memory und min server memory gleichmäßig auf die NUMA-Knoten verteilt. Wenn Sie auf dem System mit vier Knoten beispielsweise max server memory auf 16 GB festlegen, ordnet der Pufferpool jedem Knoten 4 GB Arbeitsspeicher zu. Wenn Sie einen der Knoten offline schalten, indem Sie die Einstellung für affinity mask ändern, wird die Einstellung für max server memory zwischen den verbleibenden Knoten neu verteilt. Wenn Sie in dem vorhergehenden Beispiel mit vier Knoten beispielsweise zwei Knoten offline schalten, werden die freigegebenen 8 GB Arbeitsspeicher gleichmäßig unter den verbleibenden Knoten verteilt. Da der Pufferpool Fremdseiten verwenden kann, wird Remotespeicher genutzt, wenn auf den verbleibenden Knoten nicht genügend Arbeitsspeicher vorhanden ist. Wenn SQL Server keinen Arbeitsspeicher von den Knoten verwenden soll, auf denen es nicht mehr ausgeführt wird, müssen Sie die Einstellung für max server memory nach dem Offlineschalten der Knoten verringern.
Fremdseiten
Knoten arbeiten weitgehend unabhängig voneinander. Alle Arbeitsspeicherzuordnungen und Aufhebungen von Arbeitsspeicherzuordnungen für einen Knoten werden mithilfe des Arbeitsspeichers des jeweiligen Knotens ausgeführt. Wenn jedoch ein Arbeitsthread, der auf Knoten N1 ausgeführt wird, auf eine Datenbankseite zugreifen muss, die sich bereits im Arbeitsspeicher von Knoten N2 befindet, greift er auf den nicht lokalen Arbeitsspeicher zu.
Beobachten von lokalem Arbeitsspeicher und Fremdarbeitsspeicher im Pufferpool
Der Pufferpool kann beobachtet werden, indem das Buffer Node-Objekt angezeigt wird. Der Gesamtspeicher im Pufferpool für SQL Server wird als Zielseiten-Leistungsindikator des SQLServer:Puffer-Manager-Objekts angezeigt. Der Speicher im Pufferpool für jeden Knoten wird als Zielseiten-Leistungsindikator des Buffer Node-Objekts angezeigt. Arbeitsspeicher von anderen Knoten wird als Leistungsindikator für Fremdseiten angezeigt. Weitere Informationen finden Sie unter SQL Server, Buffer Node (Objekt) und SQL Server, Puffer-Manager-Objekt.
Jeder Knoten führt Prüfpunkte für seinen eigenen Arbeitsspeicher aus
Jeder Arbeitsspeicherknoten hat einen eigenen LAZY WRITER-Thread (verzögertes Schreiben). Dieser Thread wird sowohl für implizite als auch für explizite Prüfpunkte aufgerufen. Da ein Computer mit symmetrischem Multiprocessing (Symmetric Multiprocessing, SMP) nur einen Prüfpunktthread aufweist, führen mehrere Threads beim Verwenden von NUMA zu einer Erhöhung der Geschwindigkeit des Prüfpunkts.
Tabellenscanverhalten
Ein auf Knoten N1 ausgeführter Tabellenscan füllt nur den Arbeitsspeicher von Knoten N1, es sei denn, der Scan wird parallel auf CPUs von mehreren Knoten ausgeführt. Wenn der Scan exklusiv auf einem einzelnen Knoten ausgeführt wird, werden nur die Pufferseiten von diesem Knoten verwendet. Dies trägt dazu bei, die Auslastung für eine Anwendung zu partitionieren.