Arbeitsspeicheroptimierte tempdb-Metadaten (HkTempDB) – Fehler bei Arbeitsspeichermangel
Dieser Artikel enthält Lösungen zur Behandlung von Problemen mit nicht genügend Arbeitsspeicher im Zusammenhang mit der speicheroptimierten tempdb Metadatenfunktion.
Symptome
Nachdem Sie das Feature für speicheroptimierte tempdb Metadaten (HkTempDB) aktiviert haben, wird möglicherweise der Fehler 701 angezeigt, der auf Ausnahmen mit nicht genügend Arbeitsspeicher für tempdb Zuordnungen und SQL Server Dienstabstürze hinweist. Darüber hinaus können Sie feststellen, dass der Memory-Clerk MEMORYCLERK_XTP für In-Memory OLTP (Hekaton) allmählich oder schnell wächst und nicht zurückschrumpft. Da der XTP-Arbeitsspeicher ohne Obergrenze wächst, wird die folgende Fehlermeldung in SQL Server angezeigt:
Die Zuordnung von Seiten für die Datenbank "tempdb" wird aufgrund von unzureichendem Arbeitsspeicher im Ressourcenpool "default" nicht zugeordnet. 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 die Speicherbearbeiter MEMORYCLERK_XTPhoch ist. Zum 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:
Erfassen Sie ein einfaches Ablaufverfolgungs- oder erweitertes Ereignis (XEvent), um die Workload zu verstehen
tempdbund herauszufinden, ob die Workload explizite Transaktionen mit langer Ausführungsdauer mit DDL-Anweisungen für temporäre Tabellen enthält.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 Lö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 unter Schritte zur Entschärfung, um den speicheroptimierten tempdb-Metadatenspeicher zu überprüfen.
Allmählicher Anstieg des XTP-Arbeitsspeicherverbrauchs
Szenario 1
Die DMV tempdb.sys.dm_xtp_system_memory_consumers oder tempdb.sys.dm_db_xtp_memory_consumers weist einen großen Unterschied zwischen zugeordneten und verwendeten Bytes auf.
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.Hinweis
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 zugeordnete und verwendete Bytes für SpeicherconsumertypenVARHEAPundLOOKASIDEan.Lösung: Überprüfen Sie auf explizite Transaktionen mit langer Ausführungsdauer, die DDL-Anweisungen in temporären Tabellen betreffen, und lösen Sie sie von der Anwendungsseite aus, indem Sie Transaktionen kurz halten.
Hinweis
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 sie lange geöffnet lassen, wenn andere Aktivitäten stattfinden.
Szenario 3
Die DMV
tempdb.sys.dm_db_xtp_memory_consumerszeigt hohe Werte für zugeordnete und verwendete Bytes in einer LOB-Zuweisung (Large Object) oder einem Tabellenheap an, wobeiObject_ID,XTP_Object_IDundIndex_IDsindNULL.Lösung: Wenden Sie SQL Server 2019 CU16 für das Problem 14535149 an.
Szenario 4
Der XTP-Datenbank-Speicherconsumer "VARHEAP\Storage internal heap" führt zu einem Fehler 41805, der nicht genügend Arbeitsspeicher aufweist.
Lösung: Das Problem 14087445 bereits in SQL Server 17 CU25 und höheren Versionen identifiziert und behoben, um auf SQL Server 2019 portiert zu werden.
Plötzlicher Anstieg oder schneller Anstieg des XTP-Speicherverbrauchs
Szenario 5
Die DMV
tempdb.sys.dm_db_xtp_memory_consumerszeigt hohe Werte für zugeordnete oder verwendete Bytes in einem Tabellenheap an, wobeiObject_IDnichtNULList. Die häufigste Ursache für dieses Problem ist eine zeitintensive, explizit geöffnete Transaktion mit DDL-Anweisungen für temporäre Tabellen. Zum 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 Tabellenheap und der Lookaside-Heap mithilfe von
tempdbMetadaten für nachfolgende Transaktionen freigegeben werden.Lösung: Überprüfen Sie auf explizite Transaktionen mit langer Ausführungsdauer, die DDL-Anweisungen in temporären Tabellen betreffen, und lösen Sie sie von der Anwendungsseite aus, indem Sie Transaktionen kurz halten.
Schritte zur Entschärfung, um den speicheroptimierten tempdb-Metadatenspeicher zu überprüfen
Um zeitintensive Transaktionen zu vermeiden oder aufzulösen, die DDL-Anweisungen für temporäre Tabellen verwenden, ist die allgemeine Anleitung, Transaktionen kurz zu halten.
Erhöhen Sie den maximalen Serverarbeitsspeicher , um genügend Arbeitsspeicher für den Betrieb bei tempdb-starken Workloads zu ermöglichen.
Führen Sie in regelmäßigen Abständen aus
sys.sp_xtp_force_gc.Um den Server vor möglichen Nicht-Arbeitsspeicher-Bedingungen zu schützen, können Sie tempdb an einen Resource Governor Ressourcenpool binden. Erstellen Sie beispielsweise einen Ressourcenpool mit
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>');Diese Änderung erfordert einen Neustart, um wirksam zu werden, auch wenn speicheroptimierte
tempdbMetadaten bereits aktiviert sind. Weitere Informationen finden Sie unter:Warnung
Nach dem Binden von HktempDB an einen Pool erreicht der Pool möglicherweise seine maximale Einstellung, und alle Abfragen, die verwenden
tempdb, können mit Fehlern aufgrund von nicht genügend Arbeitsspeicher fehlschlagen. Zum Beispiel:Die Zuordnung von Seiten für die Datenbank "tempdb" wird aufgrund von unzureichendem Arbeitsspeicher im Ressourcenpool "HkTempDB" nicht zugeordnet. Weitere Informationen finden Sie unter "
http://go.microsoft.com/fwlink/?LinkId=510837". Fehler bei der XTP-Seitenzuordnung aufgrund von Arbeitsspeicherauslastung: FAIL_PAGE_ALLOCATION 8Unter bestimmten Umständen kann der SQL Server Dienst möglicherweise beendet werden, wenn ein Fehler aufgrund von unzureichendem Arbeitsspeicher auftritt. Um die Wahrscheinlichkeit zu verringern, dass dies geschieht, legen Sie die des Speicherpools
MAX_MEMORY_PERCENTauf einen hohen Wert fest.Das speicheroptimierte
tempdbMetadatenfeature 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 Ihre Workload solche Transaktionen enthält und Sie deren Dauer nicht steuern können, ist dieses Feature möglicherweise nicht für Ihre Umgebung geeignet. Sie sollten ausführliche Tests durchführen, bevor Sie verwendenHkTempDB.
Weitere Informationen
In diesen Abschnitten finden Sie weitere Informationen zu einigen der Speicherkomponenten, die an speicheroptimierten tempdb Metadaten beteiligt sind.
Lookaside-Speicherzuordnung
Lookaside in In-Memory OLTP ist eine threadlokale Speicherzuweisung, um eine schnelle Transaktionsverarbeitung zu erreichen. Jedes Threadobjekt enthält eine Auflistung von Lookaside-Speicherzuordnungen. Jede Lookaside, die jedem Thread zugeordnet ist, verfügt über eine vordefinierte Obergrenze, wie viel Arbeitsspeicher zugewiesen werden kann. Wenn der Grenzwert erreicht ist, ordnet der Thread Arbeitsspeicher aus einem Freigegebenen SpeicherpoolVARHEAP 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').
Consumer auf Systemebene: tempdb.sys.dm_xtp_system_memory_consumers
Ungefähr 25 Lookaside-Speicherverbrauchertypen sind die Obergrenze. Wenn Threads mehr Arbeitsspeicher von diesen Lookasiden benötigen, wird der Speicher auf den Lookaside-Heap übertragen und ist mit dem Lookaside-Heap zufrieden. Hohe Werte für verwendete Bytes können ein Indikator für eine konstant hohe tempdb Arbeitsauslastung und/oder eine lange 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_consumers
Die LOB-Zuweisung wird für Systemtabellen lob/off-row-Daten verwendet.
Der Tabellenheap wird für Systemtabellenzeilen verwendet.
Hohe Werte für verwendete Bytes können der Indikator für eine konstant hohe tempdb Arbeitsauslastung und/oder eine lange geöffnete Transaktion sein, die temporäre Objekte verwendet.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für