Freigeben über


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:

  1. 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.

  2. 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_gc verfü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_gc
    
  • Szenario 2

    Die DMV tempdb.sys.dm_xtp_system_memory_consumers zeigt hohe Werte für zugewiesene und verwendete Bytes für Speicherverbrauchertypen VARHEAP und LOOKASIDE.

    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_consumers zeigt hohe Werte für zugeordnete und verwendete Bytes in einem Lob-Allocator oder Tabellenhap an, wobei Object_ID, XTP_Object_IDund Index_ID sind NULL.

    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_consumers zeigt hohe Werte für zugeordnete oder verwendete Bytes in einem Tabellenhap an, wobei Object_ID dies nicht NULLder 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)
        …
        …
    COMMIT
    

    Eine 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 tempdb von 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

  1. 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.

  2. Erhöhen Sie den maximalen Serverspeicher , um genügend Arbeitsspeicher zu ermöglichen, um in Anwesenheit von tempdb-schweren Workloads zu arbeiten.

  3. Wird in regelmäßigen Abständen ausgeführt sys.sp_xtp_force_gc .

  4. 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 tempdb Metadaten 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 8

    Unter 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_PERCENT auf einen hohen Wert fest.

  5. Das feature für arbeitsspeicheroptimierte tempdb Metadaten 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 Verwendung HkTempDBumfassend 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.