Metadane bazy danych tempdb zoptymalizowane pod kątem pamięci (HkTempDB) nie są błędami pamięci

Artykuł
07/30/2024

Ten artykuł zawiera rozwiązania problemów z brakiem pamięci związanych z funkcją metadanych zoptymalizowanych pod kątem tempdb pamięci.

Symptomy

Po włączeniu funkcji metadanych zoptymalizowanych pod kątem tempdb pamięci (HkTempDB) może zostać wyświetlony błąd 701 wskazujący wyjątki pamięci dla tempdb alokacji i awarii usługi PROGRAMU SQL Server. Ponadto można zauważyć, że urzędnik MEMORYCLERK_XTP pamięci dla In-Memory OLTP (Hekaton) rośnie stopniowo lub szybko i nie zmniejsza się z powrotem. W miarę zwiększania się pamięci XTP bez górnego limitu w programie SQL Server zostanie wyświetlony następujący komunikat o błędzie:

Brak zezwalania na alokacje stron dla bazy danych "tempdb" z powodu niewystarczającej ilości pamięci w puli zasobów "default". Aby uzyskać więcej informacji, zobacz "http://go.microsoft.com/fwlink/?LinkId=510837".

Po uruchomieniu zapytania na dm_os_memory_clerks DMV widać, że przydzielona pamięć stron jest wysoka dla urzędnika MEMORYCLERK_XTPpamięci. Na przykład:

SELECT type, memory_node_id, pages_kb 
FROM sys.dm_os_memory_clerks
WHERE type = 'MEMORYCLERK_XTP'

Wynik:

type                    memory_node_id                     pages_kb
------------------------------------------------------------ -------------- --------------------
MEMORYCLERK_XTP         0                                  60104496
MEMORYCLERK_XTP         64                                 0

Diagnozowanie problemu

Aby zebrać dane w celu zdiagnozowania problemu, wykonaj następujące kroki:

Zbierz uproszczone zdarzenie śledzenia lub rozszerzone (XEvent), aby zrozumieć tempdb obciążenie i sprawdzić, czy obciążenie ma długotrwałe jawne transakcje z instrukcjami DDL w tabelach tymczasowych.

Zbierz dane wyjściowe następujących widoków DMV, aby dokładniej przeanalizować.

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

Przyczyna i rozwiązanie

Korzystając z widoków DMV w celu zweryfikowania przyczyny, mogą pojawić się różne scenariusze problemu. Te scenariusze można podzielić na następujące dwie kategorie. Aby rozwiązać ten problem, możesz użyć odpowiedniego rozwiązania dla każdego scenariusza. Aby uzyskać więcej informacji na temat sposobu łagodzenia problemu, zobacz Kroki zaradcze w celu zachowania pamięci zoptymalizowanej pod kątem pamięci pamięci pamięci w pamięci w celu sprawdzenia pamięci metadanych bazy danych tempdb.

Stopniowy wzrost zużycia pamięci XTP

Scenariusz 1

Widok DMV tempdb.sys.dm_xtp_system_memory_consumers lub tempdb.sys.dm_db_xtp_memory_consumers pokazuje dużą różnicę między przydzielonych bajtów a używanymi bajtami.

Rozwiązanie: Aby rozwiązać ten problem, możesz uruchomić następujące polecenia w programie SQL Server 2019 CU13, SQL Server 2022 CU1 lub nowszej wersji, która ma nową procedurę sys.sp_xtp_force_gc zwolnienia przydzielonych, ale nieużywanych bajtów.

Uwaga 16.

Począwszy od programu SQL Server 2022 CU1, należy wykonać procedurę składowaną tylko raz.
```
/* 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
```
Scenariusz 2

Widok DMV tempdb.sys.dm_xtp_system_memory_consumers przedstawia wysokie wartości przydzielonych i używanych bajtów dla typów VARHEAP odbiorców pamięci i LOOKASIDE.

Rozwiązanie: Sprawdź długotrwałe jawne transakcje obejmujące instrukcje DDL w tabelach tymczasowych i rozwiąż je po stronie aplikacji, utrzymując krótkie transakcje.

Uwaga 16.

Aby odtworzyć ten problem w środowisku testowym, można utworzyć jawną transakcję przy użyciu instrukcji języka DDL (Data Definition Language) w tabelach tymczasowych i pozostawić je otwarte przez długi czas, gdy odbywa się inne działanie.
Scenariusz 3

Widok DMV tempdb.sys.dm_db_xtp_memory_consumers pokazuje wysokie wartości przydzielonych i używanych bajtów w alokatorze obiektów (LOB) lub stercie tabeli, gdzie Object_ID, XTP_Object_IDi Index_ID są NULL.

Rozwiązanie: Zastosuj program SQL Server 2019 CU16 do problemu 14535149.
Scenariusz 4

Stale rośnie "VARHEAP\Storage wewnętrzny sterta" odbiorca pamięci bazy danych XTP prowadzi do błędu braku pamięci 41805.

Rozwiązanie: problem 14087445 już zidentyfikowany i rozwiązany w programie SQL Server 17 CU25 i nowszych wersjach jest badany jako port do programu SQL Server 2019.

Nagły wzrost lub gwałtowny wzrost zużycia pamięci XTP

Scenariusz 5

Dynamiczny widok zarządzania tempdb.sys.dm_db_xtp_memory_consumers pokazuje wysokie wartości dla przydzielonych lub używanych bajtów w stercie tabeli, gdzie Object_ID nie NULLma wartości . Najczęstszą przyczyną tego problemu jest długotrwała, jawnie otwarta transakcja z instrukcjami DDL w tabelach tymczasowych. Na przykład:
```
BEGIN TRAN
    CREATE TABLE #T(sn int)
    …
    …
COMMIT
```
Jawnie otwarta transakcja z instrukcjami DDL w tabelach tymczasowych nie pozwoli na zwolnienie sterta tabeli i stertę odnośnika dla kolejnych transakcji przy użyciu tempdb metadanych.

Rozwiązanie: Sprawdź długotrwałe jawne transakcje obejmujące instrukcje DDL w tabelach tymczasowych i rozwiąż je po stronie aplikacji, utrzymując krótkie transakcje.

Kroki zaradcze w celu utrzymania pamięci zoptymalizowanej pod kątem pamięci pamięci pamięci w pamięci w celu zaewidencjonowania metadanych bazy danych tempdb

Aby uniknąć długotrwałych transakcji korzystających z instrukcji DDL w tabelach tymczasowych lub rozwiązać je, ogólne wskazówki dotyczą utrzymywania krótkich transakcji.
Zwiększ maksymalną ilość pamięci serwera, aby zapewnić wystarczającą ilość pamięci do działania w przypadku obciążeń o dużym obciążeniu bazy danych tempdb.
Uruchamiaj sys.sp_xtp_force_gc okresowo.
Aby chronić serwer przed potencjalnymi warunkami braku pamięci, można powiązać bazę danych tempdb z pulą zasobów zarządcy zasobów. Na przykład utwórz pulę zasobów przy użyciu polecenia MAX_MEMORY_PERCENT = 30. Następnie użyj następującego polecenia ALTER SERVER CONFIGURATION , aby powiązać pulę zasobów z metadanymi bazy danych tempdb zoptymalizowanymi pod kątem pamięci.
```
ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON (RESOURCE_POOL = '<PoolName>');
```
Ta zmiana wymaga ponownego uruchomienia, nawet jeśli metadane zoptymalizowane pod kątem tempdb pamięci są już włączone. Aby uzyskać więcej informacji, zobacz:
- Konfigurowanie i używanie metadanych bazy danych tempdb zoptymalizowanych pod kątem pamięci.
- Utwórz pulę zasobów.
Ostrzeżenie

Po powiązaniu bazy danych HktempDB z pulą pula może osiągnąć maksymalne ustawienie, a wszystkie zapytania, które używają tempdb , mogą zakończyć się niepowodzeniem z powodu błędów braku pamięci. Na przykład:

Brak zezwalania na alokacje stron dla bazy danych "tempdb" z powodu niewystarczającej ilości pamięci w puli zasobów "HkTempDB". Aby uzyskać więcej informacji, zobacz "http://go.microsoft.com/fwlink/?LinkId=510837". Alokacja strony XTP nie powiodła się z powodu użycia pamięci: FAIL_PAGE_ALLOCATION 8

W pewnych okolicznościach usługa SQL Server może potencjalnie zatrzymać się, jeśli wystąpi błąd braku pamięci. Aby zmniejszyć prawdopodobieństwo wystąpienia takiej sytuacji, ustaw pulę MAX_MEMORY_PERCENT pamięci na wartość wysoką.
Funkcja metadanych zoptymalizowanych tempdb pod kątem pamięci nie obsługuje każdego obciążenia. Na przykład użycie jawnych transakcji z instrukcjami DDL w tabelach tymczasowych uruchamianych przez długi czas doprowadzi do opisanych scenariuszy. Jeśli masz takie transakcje w obciążeniu i nie możesz kontrolować ich czasu trwania, być może ta funkcja nie jest odpowiednia dla twojego środowiska. Przed użyciem polecenia HkTempDBnależy przeprowadzić obszerne testy.

Więcej informacji

Te sekcje zawierają więcej szczegółów na temat niektórych składników pamięci związanych z metadanymi zoptymalizowanymi pod kątem tempdb pamięci.

Alokator pamięci lookaside

Lookaside in In-Memory OLTP to alokator pamięci lokalnej wątku, który pomaga w szybkim przetwarzaniu transakcji. Każdy obiekt wątku zawiera kolekcję alokatorów pamięci lookaside. Każde spojrzenie skojarzone z każdym wątkiem ma wstępnie zdefiniowany górny limit ilości pamięci, jaką może przydzielić. Po osiągnięciu limitu wątek przydziela pamięć z udostępnionej puli pamięci (VARHEAP). Widok DMV sys.dm_xtp_system_memory_consumers agreguje dane dla każdego typu lookaside (memory_consumer_type_desc = 'LOOKASIDE') i puli pamięci udostępnionej (memory_consumer_type_desc = 'VARHEAP' i memory_consumer_desc = 'Lookaside heap').

Odbiorcy na poziomie systemu: tempdb.sys.dm_xtp_system_memory_consumers

Około 25 typów odbiorców pamięci to górna granica. Gdy wątki potrzebują więcej pamięci z tych lookasides, pamięć rozla się do i jest zadowolona ze sterty lookaside. Wysokie wartości używanych bajtów mogą być wskaźnikiem ciągłego dużego tempdb obciążenia i/lub długotrwałej otwartej transakcji korzystającej z obiektów tymczasowych.

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

Odbiorcy na poziomie bazy danych: tempdb.sys.dm_db_xtp_memory_consumers

Alokator LOB jest używany w przypadku tabel systemowych LOB/Off-row danych.
Sterta tabeli jest używana w przypadku wierszy tabel systemowych.

Wysokie wartości używanych bajtów mogą być wskaźnikiem ciągłego dużego tempdb obciążenia i/lub długotrwałej otwartej transakcji używającej obiektów tymczasowych.

Udostępnij za pośrednictwem