Les requêtes prennent plus de temps à se terminer lorsque la taille du cache TokenAndPermUserStore augmente en SQL Server

  • Article

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

Numéro de la 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 constatez une baisse des performances lorsque vous exécutez une requête ad hoc. Toutefois, si vous interrogez les sys.dm_exec_requests vues de gestion dynamique ou sys.dm_os_waiting_tasks , les résultats n’indiquent pas que la requête ad hoc attend une ressource.

  • La taille du TokenAndPermUserStore cache augmente à un rythme régulier.

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

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

Cause

Les problèmes de performances tels qu’un processeur élevé et une utilisation accrue de la mémoire peuvent être dus à 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 sollicitation de la 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, la recherche d’entrées existantes à réutiliser prend plus de temps. L’accès à ce cache est contrôlé par un verrouillage tournant. Un seul thread à la fois peut effectuer la recherche. Ce comportement finit par entraîner une diminution des performances des requêtes et une utilisation plus élevée du processeur.

Pour surveiller la taille du TokenAndPermUserStore cache, vous pouvez utiliser une requête qui ressemble à 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 un SecContextToken.
    • Chaque entrée de ce cache est une seule autorisation 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 du cache des résultats de la vérification d’accès (ACR). 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 de 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.
    • La vérification d’accès indique si un utilisateur donné dans une base de données particulière a l’autorisation d’exécuter une requête qui implique plusieurs objets.
    • Avant Microsoft SQL Server 2008, les caches de sécurité ACR étaient 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 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 Access case activée cache Server Configuration Options.

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 du TokenAndPermUserStore (par défaut, il n’y a pas de 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 à 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 en ligne DBCCC TRACEON - Indicateurs de trace.

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

  • Matériel bas de gamme ou moyen-end pour lequel TokenAndPermUserStore occupe une grande quantité de mémoire disponible pour le serveur et pour lequel le taux de création de nouvelles entrées 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 plus fréquente du cache pour d’autres parties du serveur (par exemple, le cache proc).

  • Ordinateurs haut de gamme qui ont beaucoup de mémoire (par exemple, plusieurs cas de prise en charge récents impliquent plus de 1 To de RAM). Dans ces environnements, le magasin de cache peut devenir volumineux avant de faire l’objet d’une sollicitation de la mémoire. Cela peut entraîner une dégradation des performances à partir de longues chaînes de compartiments ou de longues marches.

En guise d’atténuation temporaire, vous pouvez effacer régulièrement ce cache à 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 des 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 case activée 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')