Dela via

Det tar längre tid att slutföra frågor när storleken på TokenAndPermUserStore-cachen växer i SQL Server

Den här artikeln hjälper dig att felsöka problem som rör frågeprestanda när storleken på TokenAndPermUserStore växer. Det ger också olika orsaker och lösningar.

Ursprungligt KB-nummer: 927396

Symptom

I Microsoft SQL Server får du följande symtom:

  • Frågor som vanligtvis körs snabbt tar längre tid att slutföra.

  • CPU-användningen för SQL Server-processen är större än vanligt.

  • Du får sämre prestanda när du kör en ad hoc-fråga. Men om du frågar efter sys.dm_exec_requests eller sys.dm_os_waiting_tasks dynamiska hanteringsvyer anger resultaten inte att ad hoc-frågan väntar på någon resurs.

  • Cachens TokenAndPermUserStore storlek växer stadigt.

  • Cachens TokenAndPermUserStore storlek är flera hundra megabyte (MB).

  • I vissa fall ger körning av DBCC FREEPROCCACHE kommandot eller DBCC FREESYSTEMCACHE tillfällig lättnad.

Orsak

Prestandaproblem som hög CPU-användning och ökad minnesanvändning kan orsakas av överdrivna poster i TokenAndPermUserStore cacheminnet. Som standard rensas poster i cacheminnet endast när SQL Server signalerar internt minnestryck. På servrar som har mycket RAM-minne utlöses kanske inte internt minnestryck ofta. När cacheminnet växer tar det längre tid att söka efter befintliga poster att återanvända. Åtkomst till den här cachen styrs av en spinlock. Endast en tråd i taget kan göra sökningen. Det här beteendet gör så småningom att frågeprestandan minskar och mer CPU-användning sker.

Om du vill övervaka cachens storlek TokenAndPermUserStore kan du använda en fråga som liknar följande fråga:

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

Cacheminnet TokenAndPermUserStore har följande typer av säkerhetstoken:

  • LoginToken
    • En inloggningstoken per huvudnamn på servernivå.
  • TokenPerm
    • Registrerar alla behörigheter för ett skyddsbart objekt för en UserToken och SecContextToken.
    • Varje post i den här cachen är en enda behörighet för en specifik skyddsbar. Till exempel en välj behörighet som beviljats för tabell t1 till användare u1.
    • Den här tokenposten skiljer sig från poster i ACR-cachen (Access Check Results). ACR-poster anger huvudsakligen om en användare eller inloggning har behörighet att köra en hel fråga.
  • UserToken
    • En användartoken per databas för en inloggning.
    • Lagrar information om medlemskap i roller på databasnivå.
  • SecContextToken
    • En SecContextToken har skapats per huvudnamn på servernivå.
    • Lagrar serveromfattande säkerhetskontext för ett huvudnamn.
    • Innehåller en hashtabellcache med användartoken.
    • Lagrar information om medlemskap i roller på servernivå.
  • TokenAccessResult
    • Olika klasser av TokenAccessResult-poster finns.
    • Åtkomstkontroll anger om en viss användare i en viss databas har behörighet att köra en fråga som omfattar flera objekt.
    • Före Microsoft SQL Server 2008 lagrades ACR-säkerhetscacheminnen i en enda cache, TokenAndPermUserStore.
    • I SQL Server 2008 avgränsades ACR-cacheminnena och ACR-cacheposterna spårades i sina egna enskilda användarlager. Den här separationen förbättrade prestandan och gav bättre bucketantal och kvotkontroll för cacheminnena.
    • TokenAndPermUserStore För närvarande och ACRCacheStores är de enda typerna av säkerhetscache som används. Mer information om ACR-cacheminnen finns i åtkomstkontroll av serverkonfigurationsalternativ för cache.

Du kan köra följande fråga för att få information om de olika cacheminnena och deras enskilda storlekar:

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

Du kan köra följande fråga för att identifiera vilka typer av token som växer i 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

Lösning

SQL Server erbjuder två spårningsflaggor som kan användas för att konfigurera kvoten för TokenAndPermUserStore (som standard finns det ingen kvot. Detta innebär att det kan finnas valfritt antal poster i cacheminnet).

  • TF 4618 – Begränsar antalet poster till TokenAndPermUserStore 1024.
  • TF 4618+TF 4610 – Begränsar antalet poster till TokenAndPermUserStore 8192.

Om det mycket låga antalet 4618 orsakar andra prestandaproblem använder du traceflags 4610 och 4618 tillsammans.

Spårningsflaggorna 4610 och 4618 dokumenteras i avsnittet Books Online, DBCCC TRACEON – Trace Flags.

Dessa spårningsflaggor bör användas för scenarier där den obundna tillväxten av TokenAndPermUserStore är för stor för servern. Detta inträffar vanligtvis i två typer av miljöer:

  • Maskinvara med låg slutpunkt eller medelhög slutpunkt som TokenAndPermUserStore upptar en stor mängd tillgängligt minne för servern och för vilken takten för att skapa nya inmatningar går snabbare eller lika snabbt som cacheborttagningshastigheten. Detta kan orsaka minneskonkurration och mer frekvent cache-ogiltighet för andra delar av servern (till exempel proc cache).

  • Avancerade datorer som har mycket minne (till exempel flera senaste supportärenden omfattade mer än 1 TB RAM-minne). I dessa miljöer kan cachelagret bli stort innan minnesbelastning uppstår. Detta kan orsaka prestandaförsämring från långa bucketkedjor eller promenader.

Som en tillfällig åtgärd kan du rensa cachen med jämna mellanrum med hjälp av följande metod:

  • Rensa poster från cachen TokenAndPermUserStore .

Anteckningar:

  1. Gör detta genom att köra följande kommando:

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Observera tröskelvärdet för cachestorleken TokenAndPermUserStore när problem börjar visas.

  3. Skapa ett schemalagt SQL Server Agent-jobb som utför följande åtgärder:

    • Kontrollera cachens TokenAndPermUserStore storlek. Kontrollera storleken genom att köra följande kommando:

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

    • Om cachestorleken är större än det observerade tröskelvärdet kör du följande kommando:

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')