Wykonywanie zapytań trwa dłużej, gdy rozmiar pamięci podręcznej TokenAndPermUserStore rośnie w SQL Server

Ten artykuł ułatwia rozwiązywanie problemów związanych z wydajnością zapytań w przypadku wzrostu rozmiaru TokenAndPermUserStore . Zapewnia również różne przyczyny i obejścia.

Oryginalny numer KB: 927396

Symptomy

W usłudze Microsoft SQL Server występują następujące objawy:

• Wykonywanie zapytań, które zwykle działają szybko, trwa dłużej.

• Użycie procesora CPU dla procesu SQL Server jest większe niż zwykle.

• Podczas uruchamiania zapytania ad hoc występuje spadek wydajności. Jeśli jednak zapytasz widoki zarządzania dynamicznego sys.dm_exec_requests lub sys.dm_os_waiting_tasks , wyniki nie wskazują, że zapytanie ad hoc czeka na dowolny zasób.

• Rozmiar pamięci podręcznej TokenAndPermUserStore rośnie w stałym tempie.

• Rozmiar pamięci podręcznej TokenAndPermUserStore wynosi kilkaset megabajtów (MB).

• W niektórych przypadkach uruchomienie DBCC FREEPROCCACHE polecenia lub DBCC FREESYSTEMCACHE zapewnia tymczasowe zwolnienie.

Przyczyna

Problemy z wydajnością, takie jak wysokie użycie procesora CPU i zwiększone użycie pamięci, mogą być spowodowane nadmiernymi wpisami w TokenAndPermUserStore pamięci podręcznej. Domyślnie wpisy w tej pamięci podręcznej są czyszczone tylko wtedy, gdy SQL Server sygnalizuje wewnętrzne ciśnienie pamięci. Na serwerach z dużą ilością pamięci RAM wewnętrzne ciśnienie pamięci może nie być wyzwalane często. Gdy ta pamięć podręczna rośnie, wyszukiwanie istniejących wpisów do ponownego użycia trwa dłużej. Dostęp do tej pamięci podręcznej jest kontrolowany przez spinlock. Tylko jeden wątek naraz może wykonać wyszukiwanie. To zachowanie ostatecznie powoduje spadek wydajności zapytań i większe użycie procesora CPU.

Aby monitorować rozmiar pamięci podręcznej TokenAndPermUserStore , możesz użyć zapytania podobnego do następującego zapytania:

SELECT SUM(pages_kb) AS 
   "CurrentSizeOfTokenCache(kb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

Pamięć podręczna TokenAndPermUserStore obsługuje następujące typy tokenów zabezpieczających:

• LoginToken
  • Jeden token logowania na jednostkę poziomu serwera.
• TokenPerm
  • Rejestruje wszystkie uprawnienia do zabezpieczanego obiektu dla elementów UserToken i SecContextToken.
  • Każdy wpis w tej pamięci podręcznej jest pojedynczym uprawnieniem do określonego zabezpieczanego. Na przykład wybierz uprawnienie udzielone w tabeli t1 użytkownikowi u1.
  • Ten wpis tokenu różni się od wpisów w pamięci podręcznej ACR (Access Check Results). Wpisy usługi ACR wskazują głównie, czy użytkownik lub identyfikator logowania ma uprawnienia do uruchamiania całego zapytania.
• Usertoken
  • Jeden token użytkownika na bazę danych na potrzeby logowania.
  • Przechowuje informacje o członkostwie w rolach na poziomie bazy danych.
• SecContextToken
  • Jeden secContextToken utworzony na jednostkę poziomu serwera.
  • Przechowuje kontekst zabezpieczeń dla całego serwera dla jednostki.
  • Zawiera pamięć podręczną tabeli skrótów tokenów użytkownika.
  • Przechowuje informacje o członkostwie w rolach na poziomie serwera.
• TokenAccessResult
  • Istnieją różne klasy wpisów TokenAccessResult.
  • Kontrola dostępu wskazuje, czy dany użytkownik w określonej bazie danych ma uprawnienia do uruchamiania zapytania obejmującego wiele obiektów.
  • Przed SQL Server 2008 r. pamięci podręczne zabezpieczeń usługi ACR były przechowywane w jednej pamięci podręcznej . TokenAndPermUserStore
  • W SQL Server 2008 r. pamięci podręczne usługi ACR zostały rozdzielone, a wpisy pamięci podręcznej usługi ACR były śledzone we własnych magazynach użytkowników. Ta separacja poprawiła wydajność i zapewniała lepszą liczbę zasobników i kontrolę przydziału dla pamięci podręcznych.
  • TokenAndPermUserStore Obecnie i ACRCacheStores są jedynymi rodzajami używanej pamięci podręcznej zabezpieczeń. Aby uzyskać więcej informacji na temat pamięci podręcznych usługi ACR, zobacz sprawdzanie dostępu opcji konfiguracji serwera pamięci podręcznej.

Możesz uruchomić następujące zapytanie, aby uzyskać informacje o różnych pamięciach podręcznych i ich poszczególnych rozmiarach:

SELECT type, name, pages_kb 
FROM sys.dm_os_memory_clerks 
WHERE type = 'USERSTORE_TOKENPERM'

Możesz uruchomić następujące zapytanie, aby zidentyfikować rodzaje tokenów, które rosną w programie TokenAndPermUserStore:

SELECT [name] AS "SOS StoreName",[TokenName],[Class],[SubClass], count(*) AS [Num Entries]
FROM
(SELECT name,
x.value('(//@name)[1]', 'varchar (100)') AS [TokenName],
x.value('(//@class)[1]', 'varchar (100)') AS [Class],
x.value('(//@subclass)[1]', 'varchar (100)') AS [SubClass]
FROM
(SELECT CAST (entry_data as xml),name
FROM sys.dm_os_memory_cache_entries
WHERE type = 'USERSTORE_TOKENPERM') 
AS R(x,name)
) a
GROUP BY a.name,a.TokenName,a.Class,a.SubClass
ORDER BY [Num Entries] desc

Obejście problemu

SQL Server oferuje dwie flagi śledzenia, których można użyć do skonfigurowania limitu przydziału TokenAndPermUserStore (domyślnie nie ma limitu przydziału. Oznacza to, że w tej pamięci podręcznej może znajdować się dowolna liczba wpisów).

• TF 4618 — ogranicza liczbę wpisów do TokenAndPermUserStore 1024.
• TF 4618+TF 4610 — ogranicza liczbę wpisów do TokenAndPermUserStore 8192.

Jeśli bardzo niska liczba wpisów 4618 powoduje inne problemy z wydajnością, użyj łącznie śladów 4610 i 4618.

Flagi śledzenia 4610 i 4618 są udokumentowane w temacie Books Online, DBCCC TRACEON — Trace Flags.

Te flagi śledzenia powinny być używane w scenariuszach, w których nieograniczony wzrost TokenAndPermUserStore jest zbyt duży dla serwera. Zwykle występuje to w dwóch rodzajach środowisk:

• Sprzęt niskiej lub średniej klasy, dla którego TokenAndPermUserStore zajmuje dużą ilość dostępnej pamięci dla serwera i dla którego szybkość tworzenia nowego wejścia jest szybsza lub tak szybka, jak szybkość eksmisji pamięci podręcznej. Może to spowodować rywalizację o pamięć i częstsze unieważnienie pamięci podręcznej dla innych części serwera (na przykład pamięci podręcznej proc).

• Komputery wysokiej klasy, które mają dużo pamięci (na przykład kilka ostatnich przypadków pomocy technicznej wymagało ponad 1 TB pamięci RAM). W tych środowiskach magazyn pamięci podręcznej może stać się duży, zanim wystąpi jakiekolwiek obciążenie pamięcią. Może to spowodować obniżenie wydajności z powodu długich łańcuchów zasobników lub spacerów.

W ramach tymczasowego ograniczenia ryzyka można okresowo usuwać tę pamięć podręczną przy użyciu następującej metody:

• Opróżnij wpisy z pamięci podręcznej TokenAndPermUserStore .

Uwagi:

1. Aby to zrobić, uruchom następujące polecenie:

   DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

2. Obserwuj próg rozmiaru pamięci podręcznej, TokenAndPermUserStore gdy zaczynają pojawiać się problemy.

3. Utwórz zaplanowane zadanie agenta SQL Server, które wykonuje następujące akcje:

   • Sprawdź rozmiar pamięci podręcznej TokenAndPermUserStore . Aby sprawdzić rozmiar, uruchom następujące polecenie:

     SELECT SUM(pages_kb) AS 
      "CurrentSizeOfTokenCache(kb)" 
      FROM sys.dm_os_memory_clerks 
      WHERE name = 'TokenAndPermUserStore'
     

   • Jeśli rozmiar pamięci podręcznej jest większy niż obserwowany próg, uruchom następujące polecenie:

     DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')