Leitfaden zur Speicherverwaltungsarchitektur

  • Artikel

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Windows-Manager für virtuellen Arbeitsspeicher

Die zugesicherten Bereiche des Adressraums werden vom Windows-Manager für virtuellen Arbeitsspeicher (VMM, Virtual Memory Manager) dem verfügbaren physischen Arbeitsspeicher zugeordnet.

Weitere Informationen zur von anderen Betriebssystemen unterstützten Größe des physischen Speichers finden Sie in der Windows-Dokumentation Arbeitsspeichergrenzwerte für Windows-Versionen (möglicherweise in englischer Sprache).

Mit virtuellen Speichersystemen kann mehr physischer Arbeitsspeicher zugesichert werden, als tatsächlich vorhanden ist, sodass das Verhältnis von virtuellem zu physischem Arbeitsspeicher das Verhältnis 1:1 überschreiten kann. Auf diese Weise können größere Programme auf Computern mit verschiedenen Konfigurationen des physischen Arbeitsspeichers ausgeführt werden. Wenn jedoch deutlich mehr virtueller Arbeitsspeicher verwendet wird, als die kombinierten durchschnittlichen Workingsets aller Prozesse verwenden, kann dies zu einem ungünstigen Leistungsverhalten führen.

SQL Server-Speicherarchitektur

In SQL Server wird Arbeitsspeicher nach Bedarf dynamisch reserviert und freigegeben. In der Regel muss ein Administrator nicht angeben, wie viel Arbeitsspeicher sql Server zugewiesen werden soll, obwohl die Option weiterhin vorhanden ist und in einigen Umgebungen erforderlich ist.

Eines der vorrangigen Ziele beim Entwurf jeder Datenbanksoftware ist die Minimierung der Datenträger-E/A, da Lese- und Schreibvorgänge auf dem Datenträger zu den ressourcenintensivsten Vorgängen zählen. SQL Server erstellt einen Pufferpool im Arbeitsspeicher, um Seiten aufzunehmen, die aus der Datenbank gelesen werden. Ein großer Teil des Codes in SQL Server dient dazu, die Anzahl von physischen Lese- und Schreibvorgängen zwischen dem Datenträger und dem Pufferpool zu minimieren. SQL Server versucht, ein Gleichgewicht zwischen den beiden folgenden Zielen herzustellen:

  • Verhindern, dass der Pufferpool so groß wird, dass im gesamten System nicht genügend Arbeitsspeicher verfügbar ist.
  • Minimieren physischer E/A-Vorgänge in den Datenbankdateien durch Maximieren der Größe des Pufferpools.

In einem stark geladenen System können einige große Abfragen, bei denen eine große Menge Arbeitsspeicher ausgeführt werden muss, nicht die minimale Menge des angeforderten Arbeitsspeichers abrufen und einen Timeoutfehler erhalten, während sie auf Speicherressourcen warten. Zur Behebung dieses Problems sollten Sie den Wert für die Option Abfragewartezeiterhöhen. Für eine parallele Abfrage können Sie den Wert für die Option Max. Grad an Parallelitätreduzieren.

In einem stark geladenen System unter Arbeitsspeicherdruck können Abfragen mit Zusammenführungsverknnung, Sortierung und Bitmap im Abfrageplan die Bitmap ablegen, wenn die Abfragen nicht den minimal erforderlichen Arbeitsspeicher für die Bitmap erhalten. Dies kann sich auf die Abfrageleistung auswirken und wenn der Sortiervorgang nicht in den Arbeitsspeicher passt, kann die Nutzung von Arbeitstabellen in tempdb der Datenbank erhöht werden, was zu einem Anstieg führt tempdb . Um dieses Problem zu beheben, fügen Sie physischen Arbeitsspeicher hinzu, oder optimieren Sie die Abfragen, um einen anderen und schnelleren Abfrageplan zu verwenden.

Herkömmlicher (virtueller) Speicher

Alle SQL Server-Editionen unterstützen herkömmlichen Speicher auf der 64-Bit-Plattform. Der SQL Server-Prozess kann auf den virtuellen Adressraum bis zum maximalen Betriebssystem für die x64-Architektur zugreifen (SQL Server Standard Edition unterstützt bis zu 128 GB). Bei der IA64-Architektur betrug der Grenzwert 7 TB (IA64 wird in SQL Server 2012 (11.x) und höher nicht unterstützt. Weitere Informationen finden Sie unter Speicherbeschränkungen für Windows .

Adressspeicher für Windows-Erweiterungen (AWE)

Mithilfe von Adressfenstererweiterungen (Address Windowing Extensions, AWE) und den sperrenden Seiten im Arbeitsspeicher (LPIM), die von AWE benötigt werden, können Sie den größten Teil des SQL Server-Prozessspeichers in physischem RAM unter geringen bedingungen für virtuelle Arbeitsspeicher sperren. Dies geschieht sowohl in 32-Bit- als auch in 64-Bit-AWE-Zuordnungen. Das Sperren des Arbeitsspeichers tritt auf, da der AWE-Speicher nicht über den Virtuellen Speicher-Manager in Windows durchläuft, der die Auslagerung des Arbeitsspeichers steuert. Für die AWE-Speicherzuweisungs-API sind die Sperrseiten im Speicher (SeLockMemoryPrivilege) erforderlich. Siehe "AllocateUserPhysicalPages"-Hinweise. Daher besteht der Hauptvorteil der Verwendung der AWE-API darin, den größten Teil des Arbeitsspeichers im RAM zu halten, wenn der Arbeitsspeicherdruck auf dem System besteht. Informationen dazu, wie SQL Server die Verwendung von AWE zulassen kann, finden Sie unter Aktivieren der Option "Seiten sperren" im Arbeitsspeicher.

Wenn LPIM gewährt wird, wird dringend empfohlen, den maximalen Serverspeicher (MB) auf einen bestimmten Wert festzulegen, anstatt den Standardwert von 2.147.483.647 Mb (MB) zu verlassen. Weitere Informationen finden Sie unter Server Memory Server Configuration: Manuelles Festlegen von Optionen und Sperren von Seiten im Arbeitsspeicher (LPIM).

Wenn LPIM nicht aktiviert ist, wechselt SQL Server zu herkömmlichem Arbeitsspeicher und in Fällen der Ausschöpfung des Betriebssystemspeichers kann fehler 17890 im Fehlerprotokoll gemeldet werden. Der Fehler ähnelt dem folgenden Beispiel:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

Änderungen an der Speicherverwaltung ab SQL Server 2012 (11.x)

In älteren Versionen von SQL Server wurde die Speicherzuweisung mit fünf verschiedenen Mechanismen durchgeführt:

  • Single-Page Allocator (SPA) einschließlich nur Speicherzuweisungen, die kleiner als oder gleich 8 KB im SQL Server-Prozess waren. Die Konfigurationsoptionen Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) bestimmten die Grenzen des vom SPA verbrauchten physischen Arbeitsspeichers. Der Pufferpool bildete zugleich den Mechanismus für SPA und den größten Verbraucher für Einzelseitenbelegungen.
  • Mehrseitenbelegung (Multi-Page Allocator, MPA) für Speicherbelegungen, die mehr als 8 KB erfordern.
  • CLR-Belegung, einschließlich des SQL CLR-Heaps und dessen globaler Belegungen, die während der CLR-Initialisierung erstellt werden.
  • Speicherzuweisungen für Threadstapel im SQL Server-Prozess.
  • Direkte Windows-Belegungen (Direct Windows allocations, DWA) für Speicherbelegungsanforderungen, die direkt an Windows gerichtet sind. Dazu gehören die Windows-Heap-Verwendung und direkte virtuelle Zuordnungen von Modulen, die in den SQL Server-Prozess geladen werden. Beispiele für solche Speicherbelegungsanforderungen beinhalten Belegungen von DLLs erweiterter gespeicherter Prozeduren, Objekte, die mithilfe von Automatisierungsprozeduren (sp_OA-Aufrufen) erstellt werden, und Belegungen von verknüpften Serveranbietern.

Ab SQL Server 2012 (11.x) werden Einzelseitenzuordnungen, Mehrseitenzuordnungen und CLR-Zuordnungen in einem Allocator "Beliebige Größe" zusammengefasst und in Speichergrenzwerten enthalten, die von den Konfigurationsoptionen für den maximalen Serverspeicher (MB) und min. Serverspeicher (MB) gesteuert werden. Diese Änderung ermöglichte eine genauere Größenanpassung für alle Speicheranforderungen, die den SQL Server-Speicher-Manager durchlaufen.

Wichtig

Überprüfen Sie nach dem Upgrade auf SQL Server 2012 (11.x) und höher sorgfältig die aktuellen Konfigurationen für den maximalen Serverspeicher (MB) und min. Serverspeicher (MB ). Dies liegt daran, dass diese Konfigurationen ab SQL Server 2012 (11.x) jetzt im Vergleich zu früheren Versionen mehr Speicherzuweisungen enthalten und berücksichtigen. Diese Änderungen gelten sowohl für 32-Bit- als auch für 64-Bit-Versionen von SQL Server 2012 (11.x) und SQL Server 2014 (12.x) und 64-Bit-Versionen von SQL Server 2016 (13.x) und höher.

In der folgenden Tabelle ist aufgeführt, ob ein bestimmter Typ von Speicherbelegung durch die Konfigurationsoptionen Max. Serverarbeitsspeicher (MB) und Min. Serverarbeitsspeicher (MB) gesteuert wird:

Typ der Speicherbelegung SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) Ab SQL Server 2012 (11.x)
Einzelseitenbelegungen Ja Ja, in Seitenbelegungen beliebiger Größe konsolidiert
Mehrseitenbelegungen Nein Ja, in Seitenbelegungen beliebiger Größe konsolidiert
CLR-Belegungen Nein Ja
Threadstapel-Arbeitsspeicher Nein Nein
Direkte Belegungen von Windows Nein Nein

Ab SQL Server 2012 (11.x) weist SQL Server möglicherweise mehr Arbeitsspeicher zu als der in der Einstellung für den maximalen Serverspeicher (MB) angegebene Wert. Dieses Verhalten kann auftreten, wenn der Wert "Gesamter Serverspeicher (KB)" bereits die Einstellung "Target Server Memory (KB) " erreicht hat, wie durch den maximalen Serverspeicher (MB) angegeben. Wenn aufgrund der Speicherfragmentierung nicht genügend zusammenhängender freier Arbeitsspeicher vorhanden ist, um die Anforderung von Mehrseitenspeicheranforderungen (mehr als 8 KB) zu erfüllen, kann SQL Server eine überlastende Verpflichtung ausführen, anstatt die Speicheranforderung abzulehnen.

Sobald diese Zuordnung ausgeführt wird, signalisiert die Hintergrundaufgabe "Ressourcenüberwachung" alle Speicherverbraucher, um den zugewiesenen Speicher freizugeben, und versucht, den Wert des gesamten Serverspeichers (KB) unter die Spezifikation für den Zielserverspeicher (KB) zu bringen. Daher konnte die Sql Server-Speicherauslastung die Einstellung für den maximalen Serverspeicher (MB) kurz überschreiten. In diesem Fall überschreitet der Leistungsindikator "Gesamter Serverspeicher (KB)" die Einstellungen für den maximalen Serverspeicher (MB) und den Zielserverspeicher (KB).

Dieses Verhalten wird normalerweise während folgender Vorgänge beobachtet:

  • Große Spaltenspeicherindexabfragen
  • Großer Batchmodus für Rowstore-Abfragen
  • Columnstore-Indexbuilds (re), die große Speichervolumes zum Ausführen von Hash- und Sortiervorgängen verwenden
  • Sicherungsvorgänge, für die große Speicherpuffer erforderlich sind
  • Ablaufverfolgungsvorgänge, die große Eingabeparameter speichern müssen

Änderungen an memory_to_reserve ab SQL Server 2012 (11.x)

In älteren Versionen von SQL Server hat der SQL Server-Speicher-Manager einen Teil des Prozess-virtuellen Adressraums (VAS) für die Verwendung durch den Multi-Page Allocator (MPA), CLR Allocator, Speicherzuweisungen für Threadstapel im SQL Server-Prozess und Direkte Windows-Zuordnungen (Direct Windows Allocations, DWA) zur Verfügung gestellt. Dieser Teil des virtuellen Adressbereichs wird auch als „Zu belassender Arbeitsspeicher“ oder „Nicht-Pufferpool“-Bereich bezeichnet.

Der virtuelle Adressbereich, der für diese Belegungen reserviert ist, wird durch die Konfigurationsoption memory_to_reserve festgelegt. Der von SQL Server verwendete Standardwert beträgt 256 MB.

Da der Zuweisungsverteiler "beliebige Größe" auch Zuordnungen von mehr als 8 KB verarbeitet, enthält der memory_to_reserve Wert nicht die mehrseitigen Zuordnungen. Von dieser Änderung abgesehen bleibt bei dieser Konfigurationsoption alles unverändert.

Die folgende Tabelle gibt an, ob ein bestimmter Speichertyp in den memory_to_reserve Bereich des virtuellen Adressraums für den SQL Server-Prozess fällt:

Typ der Speicherbelegung SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) und SQL Server 2008 R2 (10.50.x) Ab SQL Server 2012 (11.x)
Einzelseitenbelegungen Nein Nein, in Seitenbelegungen beliebiger Größe konsolidiert
Mehrseitenbelegungen Ja Nein, in Seitenbelegungen beliebiger Größe konsolidiert
CLR-Belegungen Ja Ja
Threadstapel-Arbeitsspeicher Ja Ja
Direkte Belegungen von Windows Ja Ja

Dynamische Speicherverwaltung

Das Standardmäßige Speicherverwaltungsverhalten des SQL Server-Datenbankmoduls besteht darin, so viel Arbeitsspeicher wie benötigt zu erhalten, ohne einen Speichermangel auf dem System zu schaffen. Das SQL Server-Datenbankmodul verwendet dazu die Speicherbenachrichtigungs-APIs in Microsoft Windows.

Wenn SQL Server den Arbeitsspeicher dynamisch verwendet, fragt es das System regelmäßig ab, um die Menge des freien Arbeitsspeichers zu ermitteln. Bei Beibehaltung dieses freien Arbeitsspeichers werden Auslagerungsvorgänge durch das Betriebssystem verhindert. Wenn weniger Arbeitsspeicher frei ist, gibt SQL Server Arbeitsspeicher an das Betriebssystem frei. Wenn mehr Arbeitsspeicher frei ist, kann SQL Server mehr Arbeitsspeicher zuweisen. SQL Server fügt Arbeitsspeicher nur hinzu, wenn die Arbeitsauslastung mehr Arbeitsspeicher erfordert; Ein ruhender Server erhöht nicht die Größe des virtuellen Adressraums. Wenn Sie feststellen, dass Der Task-Manager und der Leistungsmonitor eine stetige Abnahme des verfügbaren Speichers zeigen, wenn SQL Server die dynamische Speicherverwaltung verwendet, ist dies das Standardverhalten und sollte nicht als Speicherverlust wahrgenommen werden.

Der maximale Serverspeicher steuert die SQL Server-Speicherzuweisung, kompilierten Arbeitsspeicher, alle Caches (einschließlich des Pufferpools), Abfrageausführungsspeichererteilungen, Sperr-Manager-Speicher und CLR1-Speicher (im Wesentlichen alle speicherbearbeiter in sys.dm_os_memory_clerks).

1 CLR-Speicher wird unter max_server_memory Zuordnungen ab SQL Server 2012 (11.x) verwaltet.

Die folgende Abfrage gibt Informationen über den aktuell belegten Arbeitsspeicher zurück:

SELECT
  physical_memory_in_use_kb/1024 AS sql_physical_memory_in_use_MB,
    large_page_allocations_kb/1024 AS sql_large_page_allocations_MB,
    locked_page_allocations_kb/1024 AS sql_locked_page_allocations_MB,
    virtual_address_space_reserved_kb/1024 AS sql_VAS_reserved_MB,
    virtual_address_space_committed_kb/1024 AS sql_VAS_committed_MB,
    virtual_address_space_available_kb/1024 AS sql_VAS_available_MB,
    page_fault_count AS sql_page_fault_count,
    memory_utilization_percentage AS sql_memory_utilization_percentage,
    process_physical_memory_low AS sql_process_physical_memory_low,
    process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Stapelgrößen

Speicher für Threadstapel 1, CLR 2, erweiterte Prozedur-DLL-Dateien, die OLE DB-Anbieter, auf die von verteilten Abfragen verwiesen wird, Automatisierungsobjekte, auf die in Transact-SQL-Anweisungen verwiesen wird, und alle Speicher, die einer nicht SQL Server-DLL zugeordnet sind, werden nicht vom maximalen Serverspeicher (MB) gesteuert.

1 Informationen zu den berechneten Standardarbeitsthreads für eine bestimmte Anzahl von affinitierten CPUs im aktuellen Host finden Sie im Artikel zum Konfigurieren der Konfiguration der Serverkonfigurationsoption für max Worker Threads. SQL Server-Stapelgrößen sind wie folgt:

SQL Server-Architektur Betriebssystemarchitektur Stapelgröße
X86 (32-Bit) X86 (32-Bit) 512 KB
X86 (32-Bit) X64 (64-Bit) 768 KB
X64 (64-Bit) X64 (64-Bit) 2048 KB
IA64 (Itanium) IA64 (Itanium) 4096 KB

2 CLR-Speicher wird unter max_server_memory Zuordnungen ab SQL Server 2012 (11.x) verwaltet.

SQL Server verwendet die Speicherbenachrichtigungs-API QueryMemoryResourceNotification , um zu bestimmen, wann der SQL Server-Speicher-Manager Arbeitsspeicher zuweisen und Arbeitsspeicher freigeben kann.

Wenn SQL Server gestartet wird, wird die Größe des virtuellen Adressraums für den Pufferpool basierend auf mehreren Parametern berechnet, z. B. die Menge des physischen Arbeitsspeichers auf dem System, die Anzahl der Serverthreads und verschiedene Startparameter. SQL Server reserviert die berechnete Größe des virtuellen Adressraumes für den Pufferpool, verwendet jedoch nur die für die aktuelle Last erforderliche Größe an physischem Arbeitsspeicher.

Die Instanz greift dann je nach Arbeitsauslastung auf weiteren Arbeitsspeicher zu. Wenn mehr Benutzer Abfragen verbinden und ausführen, erhält SQL Server bei Bedarf mehr physischen Arbeitsspeicher. Eine SQL Server-Instanz erhält weiterhin physischen Arbeitsspeicher, bis sie entweder das Ziel für die maximale Serverspeicherzuweisung (MB) erreicht, oder das Betriebssystem gibt an, dass kein freier Arbeitsspeicher mehr vorhanden ist. Es gibt Arbeitsspeicher frei, wenn sie mehr als die Min Serverspeichereinstellung aufweist, und das Betriebssystem gibt an, dass es einen Mangel an freiem Arbeitsspeicher gibt.

Sobald weitere Anwendungen auf einem Computer gestartet werden, auf dem eine Instanz von SQL Server ausgeführt wird, benötigen sie Arbeitsspeicher, sodass der Umfang des freien physischen Arbeitsspeichers auf einen Wert unter dem SQL Server-Ziel fällt. Die Instanz von SQL Server passt ihren Arbeitsspeicherverbrauch an. Wenn eine andere Anwendung beendet wird und mehr Arbeitsspeicher verfügbar wird, vergrößert die Instanz von SQL Server die Speicherbelegung. SQL Server kann mehrere MB Arbeitsspeicher pro Sekunde freigeben und reservieren, um schnell auf Änderungen der Speicherbelegung zu reagieren.

Auswirkungen der Konfigurationsoptionen Min. Serverarbeitsspeicher und Max. Serverarbeitsspeicher

Die Konfigurationsoptionen für min. Serverspeicher und max. Serverspeicher legen obere und niedrigere Grenzwerte für die Vom Pufferpool und anderen Caches des Datenbankmoduls verwendete Arbeitsspeichermenge fest. Der Pufferpool erhält nicht sofort die menge an Arbeitsspeicher, der im Min serverspeicher angegeben ist. Der Pufferpool reserviert zuerst nur so viel Speicher, wie für die Initialisierung erforderlich ist. Da die Arbeitsauslastung des SQL Server-Datenbankmoduls zunimmt, erhält sie weiterhin den Speicher, der für die Unterstützung der Workload erforderlich ist. Der Pufferpool gibt keinen der abgerufenen Arbeitsspeicher frei, bis er den in min Serverspeicher angegebenen Wert erreicht. Sobald „Min. Serverarbeitsspeicher“ erreicht ist, verwendet der Pufferpool den Standardalgorithmus, um Speicher nach Bedarf zu reservieren und freizugeben. Der einzige Unterschied besteht darin, dass der Pufferpool seine Speicherzuweisung niemals unter der im Min serverspeicher angegebenen Ebene abbricht und niemals mehr Arbeitsspeicher als die im maximalen Serverspeicher (MB) angegebene Ebene erhält.

Hinweis

SQL Server als Prozess erhält mehr Arbeitsspeicher als durch die Option für den maximalen Serverspeicher (MB). Sowohl interne als auch externe Komponenten können Arbeitsspeicher außerhalb des Pufferpools zuordnen, was zusätzlichen Arbeitsspeicher belegt, der dem Pufferpool zugeordnete Speicher stellt jedoch in der Regel immer noch den größten Teil des von SQL Server verbrauchten Arbeitsspeichers dar.

Der vom SQL Server-Datenbankmodul erworbene Arbeitsspeicher hängt vollständig von der Arbeitsauslastung ab, die auf der Instanz platziert wird. Eine SQL Server-Instanz, die viele Anforderungen nicht verarbeitet, erreicht möglicherweise nie den min. Serverspeicher.

Wenn derselbe Wert sowohl für den min. Serverspeicher als auch für den maximalen Serverspeicher (MB) angegeben ist, beendet das SQL Server-Datenbankmodul, sobald der dem SQL Server-Datenbankmodul zugewiesene Speicher für diesen Wert erreicht ist, das SQL Server-Datenbankmodul nicht mehr dynamisch freizugeben und Arbeitsspeicher für den Pufferpool zu erwerben.

Wenn eine Instanz von SQL Server auf einem Computer ausgeführt wird, auf dem häufig andere Anwendungen gestartet oder beendet werden, kann das Starten anderer Anwendungen durch die Belegung und Freigabe von Speicher, die durch die Instanz von SQL Server vorgenommen wird, verlangsamt werden. Wenn SQL Server eine von mehreren Serveranwendungen ist, die auf einem einzelnen Computer ausgeführt werden, kann es darüber hinaus erforderlich sein, dass der Umfang des SQL Server zugeordneten Speichers von Systemadministratoren gesteuert wird. In diesen Fällen können Sie die Min. Serverspeicher- und max. Serverspeicheroptionen (MB) verwenden, um zu steuern, wie viel Arbeitsspeicher SQL Server verwenden kann. Die Optionen Min. Serverarbeitsspeicher und Max. Serverarbeitsspeicher werden in Megabyte angegeben. Weitere Informationen, einschließlich Empfehlungen zum Festlegen dieser Speicherkonfigurationen, finden Sie unter Konfigurationsoptionen für den Serverarbeitsspeicher.

Spezifikationen für den von SQL Server-Objekten verwendeten Arbeitsspeicher

In der folgenden Liste werden die Richtwerte für den Arbeitsspeicher beschrieben, den die einzelnen Objekte in SQL Server in Anspruch nehmen. Die aufgeführten Angaben sind Schätzwerte und können je nach Umgebung und Erstellung der Objekte variieren:

  • Sperre (durch den Sperren-Manager verwaltet): 64 Byte + 32 Byte pro Besitzer
  • Benutzerverbindung: Ungefähr (3 * network_packet_size + 94 KB)

Die Größe des Netzwerkpakets ist die Größe der TDS-Pakete (Tabular Data Stream), die für die Kommunikation zwischen Anwendungen und dem Datenbankmodul verwendet werden. Die Standardpaketgröße beträgt 4 KB und wird durch die Konfigurationsoption Netzwerkpaketgröße gesteuert.

Wenn mehrere aktive Resultsets (MARS) aktiviert sind, beträgt die Benutzerverbindung ungefähr (3 + 3 * num_logical_connections) * network_packet_size + 94 KB.

Auswirkungen von „Min. Arbeitsspeicher pro Abfrage“

Sie können mithilfe der Konfigurationsoption Min. Arbeitsspeicher pro Abfrage die Mindestmenge an Arbeitsspeicher (in KB) festlegen, die für das Ausführen einer Abfrage zugeordnet wird. Dies ist auch als minimale Arbeitsspeicherzuweisung bekannt. Alle Abfragen müssen warten, bis der mindestens erforderliche Arbeitsspeicher zugesichert werden kann oder bis der Wert überschritten wird, der in der Serverkonfigurationsoption „Abfragewartezeit“ angegeben ist, bevor die Ausführung gestartet wird. Der Wartetyp, der in diesem Szenario gesammelt wird, ist RESOURCE_SEMAPHORE.

Wichtig

Legen Sie die Min. Arbeitsspeicher pro Abfrageserverkonfigurationsoption nicht zu hoch fest, insbesondere bei sehr ausgelasteten Systemen, da dies dazu führen könnte:

  • Stärkerer Wettbewerb um Arbeitsspeicherressourcen.
  • Verringerte Parallelität durch den erhöhten Bedarf an Arbeitsspeicher für jede einzelne Abfrage, auch wenn zur Laufzeit weniger Arbeitsspeicher als in dieser Konfiguration erforderlich ist.

Empfehlungen zur Verwendung dieser Konfiguration finden Sie unter Konfigurieren der Serverkonfigurationsoption „Min. Arbeitsspeicher pro Abfrage“.

Überlegungen zur Arbeitsspeicherzuweisung

Bei der Ausführung des Zeilenmodus kann die anfängliche Speichererteilung unter keiner Bedingung überschritten werden. Wenn mehr Arbeitsspeicher als ursprünglich zugewiesen erforderlich ist, um Hash- oder Sortiervorgänge durchzuführen, laufen diese auf den Datenträger über. Ein Hashvorgang, der überläuft, wird von einer Arbeitsdatei tempdbunterstützt, während ein Sortiervorgang, der von einer Arbeitstabelle unterstützt wird.

Ein Überlauf, der während eines Sortiervorgangs auftritt, wird als Sortierwarnung bezeichnet. Sortierwarnungen deuten darauf hin, dass Sortiervorgänge nicht in den Arbeitsspeicher passen. Dazu gehören keine Sortiervorgänge, die die Erstellung von Indizes betreffen, nur Sortiervorgänge innerhalb einer Abfrage (z. B. eine ORDER BY Klausel, die in einer SELECT Anweisung verwendet wird).

Ein Überlauf, der während eines Hashvorgangs auftritt, wird als Hashwarnung bezeichnet. Hashwarnungen treten auf, wenn während eines Hashvorgangs eine Hashrekursion oder eine Beendigung des Hashings (Hashabbruch) auftritt.

  • Hash-Rekursion tritt auf, wenn die Buildeingabe nicht in den verfügbaren Speicher passt, was dazu führt, dass die Eingabe in mehrere Partitionen aufgeteilt wird, die separat verarbeitet werden. Wenn eine dieser Partitionen immer noch nicht in den verfügbaren Speicher passt, wird sie in Unterpartitionen aufgeteilt, die ebenfalls separat verarbeitet werden. Dieser Vorgang wird so lange fortgesetzt, bis jede Partition in den verfügbaren Arbeitsspeicher passt oder die maximale Rekursionsebene erreicht ist.
  • Ein Hashabbruch tritt auf, wenn ein Hashvorgang die maximale Rekursionsebene erreicht hat und ein alternativer Plan verwendet wird, um die restlichen Partitionsdaten zu verarbeiten. Diese Ereignisse können zu verringerter Leistung auf Ihrem Server führen.

Für die Batchmodusausführung kann die ursprüngliche Arbeitsspeicherzuweisung standardmäßig bis zu einem bestimmten internen Schwellenwert dynamisch erhöht werden. Dieser Mechanismus der dynamischen Arbeitsspeicherzuweisung wurde dafür entwickelt, die speicherresidente Ausführung von Hash- und Sortiervorgängen im Batchmodus zu ermöglichen. Wenn diese Vorgänge immer noch nicht in den Arbeitsspeicher passen, werden diese auf den Datenträger überlaufen.

Weitere Informationen zu den Ausführungsmodi finden Sie unter Handbuch zur Architektur der Abfrageverarbeitung.

Pufferverwaltung

Der Hauptzweck einer SQL Server -Datenbank ist das Speichern und Abrufen von Daten. Daher stellt eine hohe Ein-/Ausgabe auf dem Datenträger ein Hauptmerkmal der Datenbank-Engine dar. Datenträger-E/A-Vorgänge beanspruchen viele Ressourcen und benötigen relativ viel Zeit für die Ausführung. Daher ist SQL Server so konzipiert, dass E/A-Vorgänge möglichst effizient gestaltet werden. Die Pufferverwaltung ist eine zentrale Komponente zum Erreichen dieser Effizienz. Die Pufferverwaltungskomponente weist zwei Mechanismen auf: den Puffer-Manager, mit dem auf Datenbankseiten zugegriffen wird und mit dem sie aktualisiert werden, und den Puffercache (auch als Pufferpool bezeichnet), mit dem Datenbankdatei-E/A-Vorgänge reduziert werden.

Funktionsweise der Pufferverwaltung

Ein Puffer ist eine 8-KB-Seite im Arbeitsspeicher. Dies entspricht der Größe einer Datenseite oder Indexseite. Der Puffercache ist ebenfalls in Seiten von je 8 KB unterteilt. Mit dem Puffer-Manager werden die Funktionen verwaltet, mit denen Daten- oder Indexseiten aus Datenbankdatenträgerdateien in den Puffercache geladen und geänderte Seiten zurück auf den Datenträger geschrieben werden. Eine Seite verbleibt im Puffercache, bis der Pufferbereich vom Puffer-Manager zum Laden weiterer Daten benötigt wird. Daten werden nur dann zurück auf den Datenträger geschrieben, wenn sie geändert wurden. Daten im Puffercache können mehrfach geändert werden, bevor sie zurück auf den Datenträger geschrieben werden. Weitere Informationen finden Sie unter Lesen von Seiten und Schreiben von Seiten.

Wenn SQL Server gestartet wird, wird die Größe des virtuellen Adressraums für den Puffercache basierend auf mehreren Parametern berechnet, z. B. die Menge des physischen Arbeitsspeichers auf dem System, die konfigurierte Anzahl der maximalen Serverthreads und verschiedene Startparameter. SQL Server reserviert die berechnete Größe des virtuellen Adressraums (das Arbeitsspeicherziel) für den Puffercache, verwendet jedoch nur die für die aktuelle Last erforderliche Größe an physischem Arbeitsspeicher. Sie können die Spalten committed_target_kb und committed_kb in der Katalogsicht der sys.dm_os_sys_info abfragen, um die Anzahl der als Arbeitsspeicherziel reservierten Seiten bzw. die Anzahl der Seiten zurückzugeben, die derzeit im Puffercache committet sind.

Das Intervall zwischen dem Start von SQL Server und dem Zeitpunkt, wenn der Puffercache sein Arbeitsspeicherziel erreicht hat, wird als „Anlaufprozess“ bezeichnet. In dieser Zeit wird der Puffer mit den erforderlichen Leseanforderungen gefüllt. Beispielsweise füllt eine einzelne 8-KB-Seitenleseanforderung eine einzelne Pufferseite aus. Dies bedeutet, dass der Anlaufprozess von der Anzahl und der Art der Clientanforderungen abhängt. Dieser Prozess wird beschleunigt, indem Leseanforderungen für einzelne Seiten in ausgerichtete 8-Seiten-Anforderungen (die einen Block darstellen) transformiert werden. Dadurch kann der Anlaufprozess sehr viel schneller erfolgen, insbesondere auf Maschinen mit großem Arbeitsspeicher. Weitere Informationen zu Seiten und Umfangen finden Sie im Handbuch zur Architektur von Seiten und Schlüssen.

Einen Großteil seines Arbeitsspeichers verwendet der Puffer-Manager im SQL Server-Vorgang. Daher erfolgt eine Zusammenarbeit zwischen Puffer-Manager und Speicher-Manager, damit auch andere Komponenten die Puffer verwenden können. Der Puffer-Manager interagiert vorrangig mit den folgenden Komponenten:

  • Resource Manager zur Steuerung der gesamten Speicherauslastung und (auf 32-Bit-Plattformen) zur Steuerung der Adressraumverwendung.
  • Datenbank-Manager und das SQL Server-Betriebssystem (SQLOS) für Datei-E/A-Vorgänge auf niedriger Ebene.
  • Protokoll-Manager für Write-Ahead-Protokollierung.

Unterstützte Funktionen

Der Puffer-Manager unterstützt die folgenden Funktionen:

  • Der Puffer-Manager ist NUMA-fähig (Non-Uniform Memory Access). Außerdem werden Puffercacheseiten auf NUMA-Hardwareknoten verteilt, sodass ein Thread auf eine Pufferseite zugreifen kann, die dem lokalen NUMA-Knoten zugewiesen ist, statt den Zugriff über einen fremden Speicher vorzunehmen.

  • Der Puffer-Manager unterstützt das Hinzufügen von Arbeitsspeicher im laufenden Systembetrieb (Hot Add Memory), das dem Benutzer ermöglicht, physischen Arbeitsspeicher hinzuzufügen, ohne den Server neu starten zu müssen.

  • Es werden auch große Seiten auf 64-Bit-Plattformen vom Puffer-Manager unterstützt. Die Seitengröße ist spezifisch für die Version von Windows.

    Hinweis

    Vor SQL Server 2012 (11.x) erfordert das Aktivieren großer Seiten in SQL Server ablaufverfolgungskennzeichnung 834.

  • Der Puffer-Manager bietet zusätzliche Diagnosen, die über dynamische Verwaltungsansichten verfügbar gemacht werden. Sie können diese Ansichten verwenden, um verschiedene Betriebssystemressourcen zu überwachen, die für SQL Server spezifisch sind. Beispielsweise können Sie mithilfe der Sicht sys.dm_os_buffer_descriptors die Seiten im Puffercache überwachen.

Datenträger-E/A

Mit dem Puffer-Manager werden nur Lese- und Schreibvorgänge für die Datenbank ausgeführt. Sonstige Datei- und Datenbankvorgänge, z. B. öffnen, schließen, erweitern und verkleinern) werden von den Datei- und Datenbank-Manager-Komponenten ausgeführt.

Datenträger-E/A-Vorgänge des Puffer-Managers weisen die folgenden Merkmale auf:

  • Alle E/A-Vorgänge werden asynchron ausgeführt, sodass der aufrufende Thread die Verarbeitung fortsetzen kann, während der E/A-Vorgang im Hintergrund ausgeführt wird.
  • Alle E/A-Vorgänge werden an die aufrufenden Threads ausgegeben, sofern nicht die Option „affinity I/O“ verwendet wird. Die Option affinity I/O mask bindet die SQL Server-Datenträger-E/A an eine bestimmte Teilmenge von CPUs. In High-End-OLTP-Umgebungen (Online Transactional Processing, Onlinetransaktionsverarbeitung) für SQL Server kann diese Erweiterung die Leistung von SQL Server -Threads, die E/A verursachen, verbessern.
  • Mehrfachseiten-E/A wird durch Scatter-Gather-E/A erreicht; dadurch wird ermöglicht, dass Daten in nicht zusammenhängende Bereiche des Arbeitsspeichers oder aus diesen übertragen werden können. Damit kann der Puffercache von SQL Server problemlos gefüllt oder gelöscht werden; zugleich werden mehrere physische E/A-Anforderungen verhindert.

Lange E/A-Anforderungen

Vom Puffer-Manager werden alle seit mindestens 15 Sekunden ausstehenden E/A-Anforderungen gemeldet. Damit kann der Systemadministrator einfacher zwischen SQL Server-Problemen und Problemen im E/A-Subsystem unterscheiden. Es wird die Fehlermeldung 833 angegeben. Im SQL Server-Fehlerprotokoll wird sie wie folgt angezeigt:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Eine lange E/A kann entweder ein Lese- oder Schreibzugriff sein; sie ist derzeit nicht in der Nachricht angegeben. Bei Meldungen zu langen E/A-Vorgängen handelt es sich um Warnungen, nicht um Fehlermeldungen. Sie geben keine Probleme mit SQL Server, sondern mit dem zugrunde liegenden E/A-System an. Die Meldungen werden ausgegeben, damit der Systemadministrator die Ursache der langen Antwortzeiten von SQL Server leichter ermitteln kann und um Probleme, die nicht durch SQL Server verursacht werden, abgrenzen zu können. Daher ist keine Aktion erforderlich, aber der Systemadministrator sollte untersuchen, warum die E/A-Anforderung so lange dauerte und ob die Zeit gerechtfertigt ist.

Ursachen für lange E/A-Anforderungen

Eine lange E/A-Nachricht kann darauf hinweisen, dass eine E/A dauerhaft blockiert ist und nie abgeschlossen wird (als verlorene E/A bezeichnet), oder nur, dass sie noch nicht abgeschlossen wurde. Es ist nicht möglich, aus der Nachricht zu sagen, welches Szenario der Fall ist, obwohl eine verlorene E/A häufig zu einem Riegeltimeout führt.

Lange E/A-Vorgänge sind häufig ein Hinweis auf eine zu hohe SQL Server-Arbeitsauslastung für das Datenträgersubsystem. Ein unzureichendes Datenträgersubsystem wird in folgenden Fällen angezeigt:

  • Bei starker SQL Server-Arbeitsauslastung werden mehrere Meldungen zu langen E/A-Vorgängen im Fehlerprotokoll angezeigt.
  • Leistungsindikatoren zeigen lange Datenträgerlatenz, lange Datenträgerwarteschlangen oder keine Festplatten-Leerlaufzeit an.

Lange E/A-Vorgänge können auch durch eine Komponente im E/A-Pfad verursacht werden (z. B. durch einen Treiber, einen Controller oder durch Firmware), bei der das Bedienen einer alten E/A-Anforderung kontinuierlich verschoben wird, anstatt neuere Anforderungen zu bedienen, die näher an der aktuellen Position des Lesekopfs liegen. Die gängige Technik der Verarbeitung von Anforderungen in Priorität, basierend darauf, welche der aktuellen Position des Lese-/Schreibkopfs am nächsten sind, wird als "Aufzugssuche" bezeichnet. Dies kann schwierig sein, mit dem Tool "Leistungsüberwachung" zu bestätigen, da die meisten I/Os umgehend gewartet werden. Lange E/A-Anforderungen werden durch Arbeitsauslastungen erschwert, bei denen viele sequenzielle E/A-Anforderungen (z. B. Sichern und Wiederherstellen, Prüfen von Tabellen, Sortieren, Erstellen von Indizes, Massenladen und Dateien auf Null setzen) ausgeführt werden.

Isolierte lange I/Os, die nicht mit einer der vorherigen Bedingungen zusammenhängen, können durch ein Hardware- oder Treiberproblem verursacht werden. Das Systemereignisprotokoll enthält möglicherweise ein ähnliches Ereignis, mit dem eine Problemdiagnose vorgenommen werden kann.

Ermittlung hoher Arbeitsspeicherauslastung

Die hohe Arbeitsspeicherauslastung ist ein Zustand, der sich aus einem Speicherengpass ergibt und zu Folgendem führen kann:

  • Zusätzliche E/A-Vorgänge (z.B. sehr aktive LAZY WRITER-Hintergrundthreads)
  • Höheres Neukompilierungsverhältnis
  • Länger ausgeführte Abfragen (wenn Wartevorgänge für die Arbeitsspeicherzuweisung vorhanden sind)
  • Zusätzliche CPU-Zyklen

Diese Situation kann durch externe oder interne Ursachen ausgelöst werden. Folgende externe Ursachen sind möglich:

  • Wenig physischer Speicher (RAM) ist verfügbar. Dadurch kürzt das System die Workingsets der derzeit ausgeführten Prozesse, wodurch das gesamte System verlangsamt werden kann. SQL Server kann das Commitziel des Pufferpools reduzieren und mit dem Kürzen interner Caches häufiger beginnen.
  • Es ist insgesamt wenig Systemspeicher (einschließlich der Auslagerungsdatei des Betriebssystems) verfügbar. Dadurch schlagen Speicherbelegungen durch das System möglicherweise fehl, da der derzeit zugewiesene Arbeitsspeicher nicht ausgelagert werden kann.

Folgende interne Ursachen sind möglich:

  • Reagieren auf den druck des externen Arbeitsspeichers, wenn das SQL Server-Datenbankmodul geringere Speicherauslastungsgrenzen festlegt.
  • Die Arbeitsspeichereinstellungen wurden manuell gesenkt, indem die Konfiguration Max. Serverarbeitsspeicher reduziert wurde.
  • Änderungen an der Arbeitsspeicherverteilung der internen Komponenten zwischen den verschiedenen Caches.

Das SQL Server-Datenbankmodul implementiert ein Framework zum Erkennen und Behandeln des Arbeitsspeicherdrucks im Rahmen der dynamischen Speicherverwaltung. Dieses Framework umfasst den Hintergrundtask namens Ressourcenmonitor. Der Task „Ressourcenmonitor“ überwacht den Status von externen und internen Arbeitsspeicherindikatoren. Sobald sich der Status einer dieser Indikatoren ändert, berechnet dieser die entsprechende Benachrichtigung und zeigt diese an. Bei diesen Benachrichtigungen handelt es sich um interne Meldungen für jede der Engine-Komponenten. Sie werden in Ringpuffern gespeichert.

Zwei Ringpuffer enthalten Informationen, die für die dynamische Speicherverwaltung relevant sind:

  • Der Ringpuffer „Ressourcenmonitor“, der die Aktivitäten des Ressourcenmonitor nachverfolgt, z.B. ob eine hohe Arbeitsspeicherauslastung signalisiert wurde oder nicht. Dieser Ringpuffer enthält Statusinformationen abhängig von der aktuellen Bedingung von RESOURCE_MEMPHYSICAL_HIGH, , RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADYoder RESOURCE_MEMVIRTUAL_LOW.
  • Der Ringpuffer „Speicherbroker“, der Datensätze von Arbeitsspeicherbenachrichtigungen für jeden Resource Governor-Ressourcenpool enthält. Wenn eine interne hohe Arbeitsspeicherauslastung ermittelt wird, wird eine Benachrichtigung, dass wenig Arbeitsspeicher vorhanden ist, für Komponenten aktiviert, denen Arbeitsspeicher zugewiesen ist. Dadurch sollen Aktionen ausgelöst werden, die den Arbeitsspeicher zwischen Caches ausgleichen.

Speicherbroker überwachen den von jeder Komponente angeforderten Arbeitsspeicherverbrauch und berechnen dann auf Basis der gesammelten Informationen den optimalen Arbeitsspeicher für jede dieser Komponenten. Es gibt mehrere Broker für jeden Resource Governor-Ressourcenpool. Diese Information wird dann an jede der Komponenten übermittelt, und die Arbeitsspeichernutzung wird entsprechend erhöht oder gesenkt.

Weitere Informationen zu Speicherbrokern finden Sie unter sys.dm_os_memory_brokers.

Fehlererkennung

Datenbankseiten können einen von zwei optionalen Mechanismen verwenden, mit denen die Integrität der Seite ab dem Zeitpunkt, zu dem sie auf den Datenträger geschrieben wird, sichergestellt wird, bis sie erneut gelesen wird: Tornseitenschutz und Prüfsummenschutz. Anhand dieser Mechanismen kann die richtige Funktionsweise des Datenspeichers, der Hardwarekomponenten (Controller, Treiber, Kabel) und des Betriebssystems unabhängig geprüft werden. Der Schutz wird der Seite hinzugefügt, bevor sie auf den Datenträger geschrieben wird, und überprüft, wenn die Seite vom Datenträger gelesen wird.

SQL Server wiederholt Lesevorgänge, die wegen eines Prüfsummenfehlers, einer zerrissenen Seite oder eines anderen E/A-Fehlers fehlschlagen, vier Mal. Ist der Lesevorgang bei einem dieser Wiederholungsversuche erfolgreich, wird eine Meldung in das Fehlerprotokoll geschrieben, und der Befehl, der den Lesevorgang ausgelöst hat, wird fortgesetzt. Schlagen alle Wiederholungsversuche fehl, schlägt der Befehl mit Fehlermeldung 824 fehl.

Die Art des verwendeten Seitenschutzes stellt ein Attribut der Datenbank dar, in der die Seite enthalten ist. Der Prüfsummenschutz ist der Standardschutz für Datenbanken, die in SQL Server 2005 (9.x) und höher erstellt wurden. Der Seitenschutzmechanismus wird zur Erstellungszeit der Datenbank angegeben und kann mithilfe der Verwendung ALTER DATABASE SETgeändert werden. Sie können die aktuelle Seitenschutzeinstellung ermitteln, indem Sie die page_verify_option Spalte in der Sys.databases-Katalogansicht oder die IsTornPageDetectionEnabled Eigenschaft der DATABASEPROPERTYEX-Funktion abfragen.

Hinweis

Bei einer Änderung der Seitenschutzeinstellungen haben die neuen Einstellungen nicht unmittelbar Auswirkungen auf die gesamte Datenbank. Stattdessen wird von Seiten die aktuelle Schutzebene der Datenbank übernommen, wenn der nächste Schreibvorgang für die Seite erfolgt. Dies bedeutet, dass in der Datenbank Seiten mit unterschiedlichem Schutz enthalten sein können.

Seitenschutz

Der in SQL Server 2000 (8.x) eingeführte Torn-Seitenschutz ist in erster Linie eine Möglichkeit, Seitenbeschädigungen aufgrund von Stromausfällen zu erkennen. Beispielsweise kann der Fall eintreten, dass durch einen unerwarteten Stromausfall nur ein Teil einer Seite auf den Datenträger geschrieben wird. Wenn Schutz vor zerrissenen Seiten festgelegt ist, wird beim Schreiben der Seite auf den Datenträger für jeden Sektor von 512 Byte auf einer Datenbankseite von 8 KB ein bestimmtes 2-Bit-Signaturmuster gespeichert und im Kopf der Datenbankseite gespeichert.

Wenn die Seite vom Datenträger gelesen wird, werden die im Seitenkopf gespeicherten zerrissenen Bits mit den tatsächlichen Seitensektorinformationen verglichen. Das Signaturmuster wechselt zwischen binär 01 und 10 mit jedem Schreibvorgang, sodass es immer möglich ist, zu erkennen, wann nur ein Teil der Sektoren es auf dem Datenträger erstellt hat: Wenn sich ein Bit im falschen Zustand befindet, wenn die Seite später gelesen wird, wurde die Seite falsch geschrieben und eine torn-Seite wird erkannt. Die Erkennung von Tornseiten verwendet minimale Ressourcen; Allerdings werden nicht alle Fehler erkannt, die durch Datenträgerhardwarefehler verursacht werden. Informationen zum Festlegen der Verschiebung der Seitenerkennung finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).For information on setting torn page detection, see ALTER DATABASE SET Options (Transact-SQL).

Prüfsummenschutz

Prüfsummenschutz, der in SQL Server 2005 (9.x) eingeführt wurde, bietet eine stärkere Überprüfung der Datenintegrität. Eine Prüfsumme wird für die Daten berechnet, die in den einzelnen Seiten geschrieben werden, und im Seitenkopf gespeichert. Wenn eine Seite, deren Prüfsumme gespeichert wird, vom Datenträger gelesen wird, wird von der Datenbank-Engine die Prüfsumme für die Daten in der Seite neu berechnet. Wenn die neue Prüfsumme von der gespeicherten Prüfsumme abweicht, wird der Fehler 824 ausgegeben. Mithilfe des Prüfsummenschutzes können mehr Fehler ermittelt werden als mithilfe des Schutzes vor zerrissenen Seiten, da sich jedes in der Seite enthaltene Byte auf dieses Verfahren auswirkt. Der Prüfsummenschutz ist jedoch relativ ressourcenintensiv.

Wenn die Prüfsumme aktiviert ist, werden durch Stromausfälle oder fehlerhafte Hard- oder Firmware verursachte Fehler erkannt, sobald die Seite vom Puffer-Manager vom Datenträger gelesen wird. Informationen zum Festlegen der Prüfsumme finden Sie unter ALTER DATABASE SET Options (Transact-SQL).For information on setting checksum, see ALTER DATABASE SET Options (Transact-SQL).

Wichtig

Wenn ein Benutzer oder eine Systemdatenbank auf SQL Server 2005 (9.x) oder höher aktualisiert wird, wird der PAGE_VERIFY Wert (NONE oder TORN_PAGE_DETECTION) beibehalten. Es wird dringend empfohlen, die Verwendung zu verwenden CHECKSUM. TORN_PAGE_DETECTION kann weniger Ressourcen verwenden, bietet jedoch eine minimale Teilmenge des CHECKSUM Schutzes.

Grundlegendes zum nicht einheitlichen Speicherzugriff

SQL Server ist nicht einheitlicher Speicherzugriff (NUMA) bekannt und eignet sich gut auf NUMA-Hardware ohne spezielle Konfiguration. Mit immer schnelleren Prozessoren und einer wachsenden Anzahl von Prozessoren wird es zunehmend schwieriger, die Speicherlatenzzeit zu verringern, die für die Verwendung dieser zusätzlichen Verarbeitungsleistung erforderlich ist. Für die Umgehung dieser Schwierigkeit stellen Hardwarehersteller große L3-Caches bereit; dies ist jedoch nur eine eingeschränkte Lösung. Die NUMA-Architektur bietet eine skalierbare Lösung für dieses Problem.

SQL Server kann die Vorteile NUMA-basierter Computer nutzen, ohne dass Anwendungsänderungen erforderlich sind. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren von SQL Server für die Verwendung von Soft-NUMA.

Dynamische Partitionierung von Speicherobjekten

Heap-Allocatoren, die in SQL Server als Speicherobjekte bezeichnet werden, ermöglichen dem Datenbankmodul das Zuweisen von Speicher aus dem Heap. Diese können mithilfe der sys.dm_os_memory_objects-DMV nachverfolgt werden.

CMemThread ist ein threadsicherer Speicherobjekttyp, der gleichzeitige Speicherzuordnungen von mehreren Threads zulässt. Zur ordnungsgemäßen Nachverfolgung verwenden CMemThread-Objekte Synchronisierungskonstrukte (Mutex), um sicherzustellen, dass nur ein einzelner Thread wichtige Informationen gleichzeitig aktualisiert.

Hinweis

Der CMemThread-Objekttyp wird während der gesamten Datenbankmodul-Codebasis für viele verschiedene Zuordnungen verwendet und kann global, nach Knoten oder cpu partitioniert werden.

Die Verwendung von Mutexen kann jedoch zu Konflikten führen, wenn viele Threads hochgradig parallel aus demselben Speicherobjekt zuordnen. Daher hat SQL Server das Konzept von partitionierten Speicherobjekten (PMO), und jede Partition wird durch ein einzelnes CMemThread-Objekt dargestellt. Die Partitionierung eines Speicherobjekts ist statisch definiert und kann nach der Erstellung nicht mehr geändert werden. Da Speicherzuordnungsmuster aufgrund von Aspekten wie Hardware und Speicherauslastung stark variieren, ist es nicht möglich, das perfekte Partitionierungsmuster vorab festzulegen.

In den meisten Fällen reicht die Verwendung einer einzelnen Partition aus, aber in einigen Szenarien kann dies zu Konflikte führen, die nur mit einem stark partitionierten Speicherobjekt verhindert werden können. Es ist nicht wünschenswert, jedes Speicherobjekt zu partitionieren, da mehr Partitionen zu anderen Ineffizienzen führen und die Speicherfragmentierung erhöhen können.

Hinweis

Vor SQL Server 2016 (13.x) könnte das Ablaufverfolgungskennzeichnung 8048 verwendet werden, um zu erzwingen, dass ein knotenbasiertes PMO zu einem CPU-basierten PMO wird. Ab SQL Server 2014 (12.x) SP2 und SQL Server 2016 (13.x) ist dieses Verhalten dynamisch und vom Modul gesteuert.

Ab SQL Server 2014 (12.x) SP2 und SQL Server 2016 (13.x) kann das Datenbankmodul inhalte für ein bestimmtes CMemThread-Objekt dynamisch erkennen und das Objekt zu einer pro-CPU-basierten Implementierung heraufstufen. Nach dem Höhergestuft bleibt das PMO höhergestuft, bis der SQL Server-Prozess neu gestartet wird. CMemThread-Contention kann durch das Vorhandensein von hohen CMEMTHREAD-Wartezeiten im sys.dm_os_wait_stats DMV erkannt werden, und durch Beobachten der sys.dm_os_memory_objects DMV-Spalten contention_factor, , partition_type, exclusive_allocations_countund waiting_tasks_count.

Nächste Schritte