Las consultas tardan más tiempo en finalizarse cuando el tamaño de la memoria caché de TokenAndPermUserStore crece en SQL Server

Este artículo le ayuda a solucionar problemas relacionados con el rendimiento de las consultas cuando crece el tamaño de TokenAndPermUserStore . También proporciona varias causas y soluciones alternativas.

Número de KB original: 927396

Síntomas

En Microsoft SQL Server, experimenta los síntomas siguientes:

• Las consultas que normalmente se ejecutan rápidamente tardan más tiempo en finalizar.

• El uso de CPU para el proceso de SQL Server es mayor de lo habitual.

• Se ha reducido el rendimiento al ejecutar una consulta ad hoc. Sin embargo, si consulta las sys.dm_exec_requests vistas de administración dinámica o sys.dm_os_waiting_tasks , los resultados no indican que la consulta ad hoc está esperando cualquier recurso.

• El tamaño de la TokenAndPermUserStore memoria caché crece a una velocidad constante.

• El tamaño de la TokenAndPermUserStore memoria caché es varios cientos de megabytes (MB).

• En algunos casos, la ejecución del DBCC FREEPROCCACHE comando o DBCC FREESYSTEMCACHE proporciona alivio temporal.

Causa

Los problemas de rendimiento, como el uso elevado de CPU y el aumento de la memoria, pueden deberse a entradas excesivas en la TokenAndPermUserStore memoria caché. De forma predeterminada, las entradas de esta memoria caché solo se limpian cuando SQL Server señala la presión de memoria interna. En los servidores que tienen mucha RAM, es posible que la presión de memoria interna no se desencadene con frecuencia. Cuando esta memoria caché crece, se tarda más tiempo en buscar entradas existentes para reutilizarlas. El acceso a esta memoria caché se controla mediante un bloqueo de número. Solo un subproceso a la vez puede realizar la búsqueda. Con el tiempo, este comportamiento hace que el rendimiento de las consultas disminuya y se produzca un mayor uso de la CPU.

Para supervisar el tamaño de la TokenAndPermUserStore memoria caché, puede usar una consulta similar a la siguiente:

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

La TokenAndPermUserStore memoria caché mantiene los siguientes tipos de token de seguridad:

• LoginToken
  • Un token de inicio de sesión por entidad de seguridad de nivel de servidor.
• TokenPerm
  • Registra todos los permisos de un objeto protegible para un UserToken y SecContextToken.
  • Cada entrada de esta memoria caché es un permiso único para un elemento protegible específico. Por ejemplo, un permiso select concedido en la tabla t1 al usuario u1.
  • Esta entrada de token es diferente de las entradas de la memoria caché de resultados de comprobación de acceso (ACR). Las entradas de ACR indican principalmente si un usuario o inicio de sesión tiene permiso para ejecutar una consulta completa.
• UserToken
  • Un token de usuario por base de datos para un inicio de sesión.
  • Almacena información sobre la pertenencia a roles de nivel de base de datos.
• SecContextToken
  • Un SecContextToken creado por entidad de seguridad de nivel de servidor.
  • Almacena el contexto de seguridad de todo el servidor para una entidad de seguridad.
  • Contiene una caché de tabla hash de tokens de usuario.
  • Almacena información sobre la pertenencia a roles de nivel de servidor.
• TokenAccessResult
  • Hay diferentes clases de entradas TokenAccessResult.
  • Comprobación de acceso indica si un usuario determinado de una base de datos determinada tiene permiso para ejecutar una consulta que implica varios objetos.
  • Antes de Microsoft SQL Server 2008, las cachés de seguridad de ACR se almacenaban en una única caché, TokenAndPermUserStore.
  • En SQL Server 2008, las cachés de ACR se separaron y se realizaron un seguimiento de las entradas de caché de ACR en sus propios almacenes de usuarios individuales. Esta separación mejoró el rendimiento y proporcionó un mejor recuento de cubos y un control de cuota para las cachés.
  • Actualmente, TokenAndPermUserStore y ACRCacheStores son los únicos tipos de caché de seguridad que se usan. Para obtener más información sobre las memorias caché de ACR, consulte Opciones de configuración del servidor de comprobación de acceso.

Puede ejecutar la consulta siguiente para obtener información sobre las diferentes memorias caché y sus tamaños individuales:

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

Puede ejecutar la consulta siguiente para identificar los tipos de tokens que están creciendo en 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

Solución alternativa

SQL Server ofrece dos marcas de seguimiento que se pueden usar para configurar la cuota de TokenAndPermUserStore (de forma predeterminada, no hay ninguna cuota. Esto implica que puede haber cualquier número de entradas en esta memoria caché).

• TF 4618 : limita el número de entradas en TokenAndPermUserStore a 1024.
• TF 4618+TF 4610 : limita el número de entradas en TokenAndPermUserStore a 8192.

Si el recuento de entradas muy bajo de 4618 provoca otros problemas de rendimiento, use los marcadores de seguimiento 4610 y 4618 juntos.

Las marcas de seguimiento 4610 y 4618 se documentan en el tema De los Libros en pantalla, DBCCC TRACEON - Marcas de seguimiento.

Estas marcas de seguimiento se deben usar para escenarios en los que el crecimiento sin enlazar de TokenAndPermUserStore es demasiado grande para el servidor. Esto suele ocurrir en dos tipos de entornos:

• Hardware de gama baja o mediana para el que TokenAndPermUserStore ocupa una gran cantidad de memoria disponible para el servidor y para la que la tasa de creación de nuevas entradas es más rápida o tan rápida como la tasa de expulsión de caché. Esto puede provocar contención de memoria y invalidación de caché más frecuente para otras partes del servidor (por ejemplo, caché de proc).

• Equipos de gama alta que tienen mucha memoria (por ejemplo, varios casos de soporte técnico recientes implicaban más de 1 TB de RAM). En estos entornos, el almacén de caché puede aumentar de tamaño antes de que se produzcan presiones de memoria. Esto puede provocar una degradación del rendimiento de cadenas de cubos largas o paseos.

Como mitigación temporal, puede borrar esta memoria caché periódicamente mediante el método siguiente:

• Vaciar las entradas de la TokenAndPermUserStore memoria caché.

Notas:

1. Para comprobarlo, ejecute el siguiente comando:

   DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

2. Observe el umbral del tamaño de caché TokenAndPermUserStore cuando empiecen a aparecer problemas.

3. Cree un trabajo de Agente SQL Server programado que realice las siguientes acciones:

   • Compruebe el tamaño de la TokenAndPermUserStore memoria caché. Para comprobar el tamaño, ejecute el siguiente comando:

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

   • Si el tamaño de caché es mayor que el umbral observado, ejecute el siguiente comando:

     DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')