Speicheroptimierte tempdb-Metadaten (HkTempDB) aus Speicherfehlern
Dieser Artikel enthält Lösungen zur Behebung von Arbeitsspeicherproblemen im Zusammenhang mit dem Feature für speicheroptimierte tempdb Metadaten.
Problembeschreibung
Nachdem Sie das Feature für speicheroptimierte tempdb Metadaten (HkTempDB) aktiviert haben, wird möglicherweise der Fehler 701 angezeigt, der angibt, dass nicht genügend Arbeitsspeicherausnahmen für tempdb Zuordnungen und SQL Server-Dienstabstürzen auftreten. Darüber hinaus können Sie sehen, dass der Speicherkaufmann MEMORYCLERK_XTP für In-Memory OLTP (Hekaton) allmählich oder schnell wächst und nicht zurückschrumpft. Da der XTP-Speicher ohne obere Grenze wächst, wird die folgende Fehlermeldung in SQL Server angezeigt:
Die Zuordnung von Seiten für die Datenbank "tempdb" wird aufgrund unzureichender Arbeitsspeicher im Ressourcenpool "default" nicht zugewiesen. Weitere Informationen finden Sie unter „
http://go.microsoft.com/fwlink/?LinkId=510837“.
Wenn Sie eine Abfrage für die DMV-dm_os_memory_clerks ausführen, können Sie sehen, dass der zugeordnete Seitenspeicher für speicherbearbeiter MEMORYCLERK_XTPhoch ist. Beispiel:
SELECT type, memory_node_id, pages_kb
FROM sys.dm_os_memory_clerks
WHERE type = 'MEMORYCLERK_XTP'
Ergebnis:
type memory_node_id pages_kb
------------------------------------------------------------ -------------- --------------------
MEMORYCLERK_XTP 0 60104496
MEMORYCLERK_XTP 64 0
Diagnostizieren des Problems
Führen Sie die folgenden Schritte aus, um Daten zum Diagnostizieren des Problems zu sammeln:
Sammeln Sie eine einfache Ablaufverfolgung oder ein erweitertes Ereignis (XEvent), um die Workload zu verstehen
tempdb, und erfahren Sie, ob die Workload über lange ausgeführte explizite Transaktionen mit DDL-Anweisungen für temporäre Tabellen verfügt.Sammeln Sie die Ausgabe der folgenden DMVs, um sie weiter zu analysieren.
SELECT * FROM sys.dm_os_memory_clerks SELECT * FROM sys.dm_exec_requests SELECT * FROM sys.dm_exec_sessions -- from tempdb SELECT * FROM tempdb.sys.dm_xtp_system_memory_consumers SELECT * FROM tempdb.sys.dm_db_xtp_memory_consumers SELECT * FROM tempdb.sys.dm_xtp_transaction_stats SELECT * FROM tempdb.sys.dm_xtp_gc_queue_stats SELECT * FROM tempdb.sys.dm_db_xtp_object_stats SELECT * FROM tempdb.sys.dm_db_xtp_transactions SELECT * FROM tempdb.sys.dm_tran_session_transactions SELECT * FROM tempdb.sys.dm_tran_database_transactions SELECT * FROM tempdb.sys.dm_tran_active_transactions
Ursache und Auflösung
Wenn Sie die DMVs verwenden, um die Ursache zu überprüfen, werden möglicherweise verschiedene Szenarien des Problems angezeigt. Diese Szenarien können in die folgenden beiden Kategorien unterteilt werden. Um das Problem zu beheben, können Sie die entsprechende Lösung für jedes Szenario verwenden. Weitere Informationen zum Beheben des Problems finden Sie in den Schritten zur Entschärfung, um den speicheroptimierten tempdb-Metadatenspeicher zu überprüfen.
Graduelle Zunahme der XTP-Speicherauslastung
Szenario 1
Der DMV-tempdb.sys.dm _xtp_system_memory_consumer oder tempdb.sys.dm_db_xtp_memory_consumer zeigt einen großen Unterschied zwischen zugeordneten Bytes und verwendeten Bytes an.
Lösung: Um das Problem zu beheben, können Sie die folgenden Befehle in SQL Server 2019 CU13, SQL Server 2022 CU1 oder einer höheren Version ausführen, die über eine neue Prozedur
sys.sp_xtp_force_gcverfügt, um zugeordnete, aber nicht verwendete Bytes freizugeben.Notiz
Ab SQL Server 2022 CU1 müssen Sie die gespeicherte Prozedur nur einmal ausführen.
/* Yes, 2 times for both*/ EXEC sys.sp_xtp_force_gc 'tempdb' GO EXEC sys.sp_xtp_force_gc 'tempdb' GO EXEC sys.sp_xtp_force_gc GO EXEC sys.sp_xtp_force_gcSzenario 2
Die DMV
tempdb.sys.dm_xtp_system_memory_consumerszeigt hohe Werte für zugewiesene und verwendete Bytes für SpeicherverbrauchertypenVARHEAPundLOOKASIDE.Lösung: Überprüfen Sie auf lange ausgeführte explizite Transaktionen, die DDL-Anweisungen für temporäre Tabellen umfassen, und lösen Sie sie von der Anwendung aus, indem Sie Transaktionen kurz halten.
Notiz
Um dieses Problem in einer Testumgebung zu reproduzieren, können Sie eine explizite Transaktion erstellen, indem Sie DDL-Anweisungen (Data Definition Language) für temporäre Tabellen verwenden und diese lange geöffnet lassen, wenn andere Aktivitäten stattfinden.
Szenario 3
Der DMV
tempdb.sys.dm_db_xtp_memory_consumerszeigt hohe Werte für zugeordnete und verwendete Bytes in einem Lob-Allocator oder Tabellenhap an, wobeiObject_ID,XTP_Object_IDundIndex_IDsindNULL.Lösung: Wenden Sie SQL Server 2019 CU16 für das Problem 14535149 an.
Szenario 4
Der ständig wachsende XTP-Datenbankspeicher-Speicherverbraucher "VARHEAP\Storage internal heap" führt zu einem Speicherfehler 41805.
Lösung: Das Problem 14087445 bereits in SQL Server 17 CU25 und höheren Versionen identifiziert und behoben wurde, wird untersucht, um zu SQL Server 2019 portiert zu werden.
Plötzliche Spitzen- oder schnelle Zunahme der XTP-Speicherauslastung
Szenario 5
Der DMV
tempdb.sys.dm_db_xtp_memory_consumerszeigt hohe Werte für zugeordnete oder verwendete Bytes in einem Tabellenhap an, wobeiObject_IDdies nichtNULLder Wert ist. Die häufigste Ursache für dieses Problem ist eine lange ausgeführte, explizit geöffnete Transaktion mit DDL-Anweisungen für temporäre Tabellen. Beispiel:BEGIN TRAN CREATE TABLE #T(sn int) … … COMMITEine explizit geöffnete Transaktion mit DDL-Anweisungen für temporäre Tabellen lässt nicht zu, dass der Tabellenhap und lookaside Heap für nachfolgende Transaktionen mithilfe
tempdbvon Metadaten freigegeben werden.Lösung: Überprüfen Sie auf lange ausgeführte explizite Transaktionen, die DDL-Anweisungen für temporäre Tabellen umfassen, und lösen Sie sie von der Anwendung aus, indem Sie Transaktionen kurz halten.
Entschärfungsschritte, um den speicheroptimierten tempdb-Metadatenspeicher zu überprüfen
Um lange ausgeführte Transaktionen zu vermeiden oder aufzulösen, die DDL-Anweisungen für temporäre Tabellen verwenden, besteht die allgemeine Anleitung darin, Transaktionen kurz zu halten.
Erhöhen Sie den maximalen Serverspeicher , um genügend Arbeitsspeicher zu ermöglichen, um in Anwesenheit von tempdb-schweren Workloads zu arbeiten.
Wird in regelmäßigen Abständen ausgeführt
sys.sp_xtp_force_gc.Um den Server vor potenziellen Nichtspeicherbedingungen zu schützen, können Sie tempdb an einen Ressourcenpool "Resource Governor" binden. Erstellen Sie beispielsweise einen Ressourcenpool mithilfe von
MAX_MEMORY_PERCENT = 30. Verwenden Sie dann den folgenden ALTER SERVER CONFIGURATION-Befehl , um den Ressourcenpool an speicheroptimierte tempdb-Metadaten zu binden.ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON (RESOURCE_POOL = '<PoolName>');Für diese Änderung muss ein Neustart wirksam werden, auch wenn speicheroptimierte
tempdbMetadaten bereits aktiviert sind. Weitere Informationen finden Sie unter:Warnung
Nach dem Binden von HktempDB an einen Pool kann der Pool seine maximale Einstellung erreichen, und alle Abfragen, die verwendet werden
tempdb, können mit Nichtspeicherfehlern fehlschlagen. Beispiel:Die Zuordnung von Seiten für die Datenbank "tempdb" wird aufgrund unzureichender Speicher im Ressourcenpool "HkTempDB" nicht zugewiesen. Weitere Informationen finden Sie unter „
http://go.microsoft.com/fwlink/?LinkId=510837“. Fehler bei der XTP-Seitenzuweisung aufgrund des Arbeitsspeicherdrucks: FAIL_PAGE_ALLOCATION 8Unter bestimmten Umständen kann der SQL Server-Dienst möglicherweise beendet werden, wenn ein Fehler außerhalb des Arbeitsspeichers auftritt. Um die Wahrscheinlichkeit zu verringern, legen Sie die Speicherpools
MAX_MEMORY_PERCENTauf einen hohen Wert fest.Das feature für arbeitsspeicheroptimierte
tempdbMetadaten unterstützt nicht jede Workload. Beispielsweise führt die Verwendung expliziter Transaktionen mit DDL-Anweisungen für temporäre Tabellen, die lange ausgeführt werden, zu den beschriebenen Szenarien. Wenn Sie solche Transaktionen in Ihrer Workload haben und ihre Dauer nicht steuern können, ist dieses Feature möglicherweise nicht für Ihre Umgebung geeignet. Sie sollten vor der VerwendungHkTempDBumfassend testen.
Weitere Informationen
Diese Abschnitte enthalten weitere Details zu einigen der Speicherkomponenten, die an speicheroptimierten tempdb Metadaten beteiligt sind.
Lookaside Memory Allocator
Lookaside in In-Memory OLTP ist ein Thread-local memory allocator, um eine schnelle Transaktionsverarbeitung zu erzielen. Jedes Threadobjekt enthält eine Auflistung von Lookaside-Speicherverknöpfern.Each thread object contains a collection of lookaside memory allocators. Jeder Lookaside, der jedem Thread zugeordnet ist, verfügt über einen vordefinierten oberen Grenzwert für die Größe, die er zuordnen kann. Wenn der Grenzwert erreicht ist, weist der Thread Speicher aus einem überlaufenden freigegebenen Speicherpool (VARHEAP) zu. Die DMV sys.dm_xtp_system_memory_consumers aggregiert Daten für jeden Lookaside-Typ (memory_consumer_type_desc = 'LOOKASIDE') und den freigegebenen Speicherpool (memory_consumer_type_desc = 'VARHEAP' und memory_consumer_desc = 'Lookaside heap').
Verbraucher auf Systemebene: tempdb.sys.dm_xtp_system_memory_consumer
Informationen zu 25 Lookaside-Speicherverbrauchstypen sind die obere Grenze. Wenn Threads mehr Arbeitsspeicher von diesen Lookasides benötigen, überläuft sich der Speicher auf den Lookaside-Heap und ist mit dem Lookaside-Heap zufrieden. Hohe Werte für verwendete Bytes können ein Indikator für konstante schwere tempdb Arbeitsauslastung und/oder lange laufende geöffnete Transaktion sein, die temporäre Objekte verwendet.
-- system memory consumers @ instance
SELECT memory_consumer_type_desc, memory_consumer_desc, allocated_bytes, used_bytes
FROM sys.dm_xtp_system_memory_consumers
memory_consumer_type_desc memory_consumer_desc allocated_bytes used_bytes
------------------------- ------------------------------------------ -------------------- --------------------
VARHEAP Lookaside heap 0 0
PGPOOL 256K page pool 0 0
PGPOOL 4K page pool 0 0
VARHEAP System heap 458752 448000
LOOKASIDE Transaction list element 0 0
LOOKASIDE Delta tracker cursor 0 0
LOOKASIDE Transaction delta tracker 0 0
LOOKASIDE Creation Statement Id Map Entry 0 0
LOOKASIDE Creation Statement Id Map 0 0
LOOKASIDE Log IO proxy 0 0
LOOKASIDE Log IO completion 0 0
LOOKASIDE Sequence object insert row 0 0
LOOKASIDE Sequence object map entry 0 0
LOOKASIDE Sequence object values map 0 0
LOOKASIDE Redo transaction map entry 0 0
LOOKASIDE Transaction recent rows 0 0
LOOKASIDE Heap cursor 0 0
LOOKASIDE Range cursor 0 0
LOOKASIDE Hash cursor 0 0
LOOKASIDE Transaction dependent ring buffer 0 0
LOOKASIDE Transaction save-point set entry 0 0
LOOKASIDE Transaction FK validation sets 0 0
LOOKASIDE Transaction partially-inserted rows set 0 0
LOOKASIDE Transaction constraint set 0 0
LOOKASIDE Transaction save-point set 0 0
LOOKASIDE Transaction write set 0 0
LOOKASIDE Transaction scan set 0 0
LOOKASIDE Transaction read set 0 0
LOOKASIDE Transaction 0 0
Consumer auf Datenbankebene: tempdb.sys.dm_db_xtp_memory_consumer
Lob allocator wird für Systemtabellen LOB/Off-Row-Daten verwendet.
Tabellen heap wird für Systemtabellenzeilen verwendet.
Hohe Werte für verwendete Bytes können der Indikator für konstante schwere tempdb Arbeitsauslastung und/oder lange laufende geöffnete Transaktion sein, die temporäre Objekte verwendet.