Partager via

Les requêtes prennent plus de temps quand la taille du cache TokenAndPermUserStore augmente dans SQL Server

  • Article

Cet article vous aide à résoudre les problèmes liés aux performances des requêtes lorsque la taille de la taille augmente TokenAndPermUserStore . Il fournit également différentes causes et solutions de contournement.

Numéro de base de connaissances d’origine : 927396

Symptômes

Dans Microsoft SQL Server, vous rencontrez les symptômes suivants :

  • Les requêtes qui s’exécutent généralement rapidement prennent plus de temps.

  • L’utilisation du processeur pour le processus SQL Server est supérieure à la normale.

  • Vous rencontrez des performances réduites lorsque vous exécutez une requête ad hoc. Toutefois, si vous interrogez les vues de gestion dynamique ou sys.dm_os_waiting_tasks les sys.dm_exec_requests vues de gestion dynamique, les résultats n’indiquent pas que la requête ad hoc attend une ressource.

  • La taille du TokenAndPermUserStore cache augmente à un rythme stable.

  • La taille du TokenAndPermUserStore cache est de plusieurs centaines de mégaoctets (Mo).

  • Dans certains cas, l’exécution de la ou DBCC FREESYSTEMCACHE de la DBCC FREEPROCCACHE commande fournit un soulagement temporaire.

Cause

Les problèmes de performances tels que le processeur élevé et l’utilisation accrue de la mémoire peuvent être causés par des entrées excessives dans le TokenAndPermUserStore cache. Par défaut, les entrées de ce cache sont nettoyées uniquement lorsque SQL Server signale une pression de mémoire interne. Sur les serveurs qui ont beaucoup de RAM, la sollicitation de la mémoire interne peut ne pas se déclencher souvent. Lorsque ce cache augmente, il faut plus de temps pour rechercher les entrées existantes à réutiliser. L’accès à ce cache est contrôlé par un verrouillage de spinlock. Un seul thread à la fois peut effectuer la recherche. Ce comportement entraîne finalement une diminution des performances des requêtes et une utilisation accrue de l’UC.

Pour surveiller la taille du TokenAndPermUserStore cache, vous pouvez utiliser une requête semblable à la requête suivante :

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

Le TokenAndPermUserStore cache gère les types de jetons de sécurité suivants :

  • LoginToken
    • Un jeton de connexion par principal au niveau du serveur.
  • TokenPerm
    • Enregistre toutes les autorisations pour un objet sécurisable pour un UserToken et SecContextToken.
    • Chaque entrée de ce cache est une autorisation unique sur un élément sécurisable spécifique. Par exemple, une autorisation de sélection accordée sur la table t1 à l’utilisateur u1.
    • Cette entrée de jeton est différente des entrées dans le cache ACR (Access Check Results). Les entrées ACR indiquent principalement si un utilisateur ou une connexion a l’autorisation d’exécuter une requête entière.
  • UserToken
    • Un jeton utilisateur par base de données pour une connexion.
    • Stocke des informations sur l’appartenance aux rôles au niveau de la base de données.
  • SecContextToken
    • Un secContextToken créé par principal au niveau du serveur.
    • Stocke le contexte de sécurité à l’échelle du serveur pour un principal.
    • Contient un cache de table de hachage des jetons utilisateur.
    • Stocke des informations sur l’appartenance aux rôles au niveau du serveur.
  • TokenAccessResult
    • Différentes classes d’entrées TokenAccessResult sont présentes.
    • Access Check indique si un utilisateur donné dans une base de données particulière a l’autorisation d’exécuter une requête impliquant plusieurs objets.
    • Avant Microsoft SQL Server 2008, les caches de sécurité ACR ont été stockés dans un seul cache. TokenAndPermUserStore
    • Dans SQL Server 2008, les caches ACR ont été séparés et les entrées du cache ACR ont été suivies dans leurs propres magasins d’utilisateurs individuels. Cette séparation a amélioré les performances et a fourni un meilleur nombre de compartiments et un meilleur contrôle de quota pour les caches.
    • Actuellement, TokenAndPermUserStore et ACRCacheStores sont les seuls types de cache de sécurité utilisés. Pour plus d’informations sur les caches ACR, consultez les options de configuration du serveur de vérification de l’accès.

Vous pouvez exécuter la requête suivante pour obtenir des informations sur les différents caches et leurs tailles individuelles :

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

Vous pouvez exécuter la requête suivante pour identifier les types de jetons qui augmentent dans le 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

Solution de contournement

SQL Server propose deux indicateurs de trace qui peuvent être utilisés pour configurer le quota de l’objet TokenAndPermUserStore (par défaut, il n’existe aucun quota. Cela implique qu’il peut y avoir n’importe quel nombre d’entrées dans ce cache).

  • TF 4618 - Limite le nombre d’entrées dans TokenAndPermUserStore 1024.
  • TF 4618+TF 4610 - Limite le nombre d’entrées en TokenAndPermUserStore 8192.

Si le nombre d’entrées très faible de 4618 provoque d’autres problèmes de performances, utilisez les traceflags 4610 et 4618 ensemble.

Les indicateurs de trace 4610 et 4618 sont documentés dans la rubrique Documentation en ligne, DBCCC TRACEON - Indicateurs de trace.

Ces indicateurs de trace doivent être utilisés pour les scénarios dans lesquels la croissance TokenAndPermUserStore illimitée est trop importante pour le serveur. Cela se produit généralement dans deux types d’environnements :

  • Matériel bas de gamme ou moyen pour lequel TokenAndPermUserStore occupe une grande quantité de mémoire disponible pour le serveur et pour lequel le taux de nouvelle création d’entrée est plus rapide ou aussi rapide que le taux d’éviction du cache. Cela peut entraîner une contention de mémoire et une invalidation de cache plus fréquente pour d’autres parties du serveur (par exemple, proc cache).

  • Les ordinateurs haut de gamme qui ont beaucoup de mémoire (par exemple, plusieurs cas de support récents impliquent plus de 1 To de RAM). Dans ces environnements, le magasin de cache peut croître en grande taille avant qu’il ne subit une pression de mémoire. Cela peut entraîner une dégradation des performances à partir de longues chaînes de compartiments ou de promenades.

En guise d’atténuation temporaire, vous pouvez effacer ce cache régulièrement à l’aide de la méthode suivante :

  • Videz les entrées du TokenAndPermUserStore cache.

Remarques :

  1. Pour ce faire, exécutez la commande suivante :

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Observez le seuil de la taille du TokenAndPermUserStore cache lorsque les problèmes commencent à apparaître.

  3. Créez un travail sql Server Agent planifié qui effectue les actions suivantes :

    • Vérifiez la taille du TokenAndPermUserStore cache. Pour vérifier la taille, exécutez la commande suivante :

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

    • Si la taille du cache est supérieure au seuil observé, exécutez la commande suivante :

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')