Compartir a través de

Las consultas tardan más tiempo en finalizar cuando el tamaño de la caché tokenAndPermUserStore crece en SQL Server.

  • Artículo

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

Número de KB original: 927396

Síntomas

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

  • 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 ningún recurso.

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

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

  • En algunos casos, ejecutar el DBCC FREEPROCCACHE comando o DBCC FREESYSTEMCACHE proporciona alivio temporal.

Causa

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

Para supervisar el tamaño de TokenAndPermUserStore la 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 userToken y SecContextToken.
    • Cada entrada de esta memoria caché es un único permiso en un elemento protegible específico. Por ejemplo, un permiso de selección concedido en la tabla t1 al usuario u1.
    • Esta entrada de token es diferente de las entradas de la 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
    • Se creó un SecContextToken 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 tablas hash de tokens de usuario.
    • Almacena información sobre la pertenencia a roles de nivel de servidor.
  • TokenAccessResult
    • Hay diferentes clases de entradas de TokenAccessResult.
    • Access Check indica si un usuario determinado de una base de datos determinada tiene permiso para ejecutar una consulta que implique varios objetos.
    • Antes de Microsoft SQL Server 2008, las memorias caché de seguridad de ACR se almacenaban en una sola caché, TokenAndPermUserStore.
    • En SQL Server 2008, las memorias caché de ACR se separaron y las entradas de caché de ACR se realizaron un seguimiento en sus propios almacenes de usuarios individuales. Esta separación mejoró el rendimiento y proporcionó un mejor número de cubos y control de cuota para las memorias caché.
    • Actualmente, TokenAndPermUserStore y ACRCacheStores son los únicos tipos de caché de seguridad que se usan. Para obtener más información sobre las cachés de ACR, consulte Opciones de configuración del servidor de comprobación de acceso de caché.

Puede ejecutar la consulta siguiente para obtener información sobre las distintas cachés 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 crecen 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 de TokenAndPermUserStore a 1024.
  • TF 4618+TF 4610 : limita el número de entradas de TokenAndPermUserStore a 8192.

Si el recuento de entradas muy bajo de 4618 provoca otros problemas de rendimiento, use las marcas de seguimiento 4610 y 4618 juntas.

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

Estas marcas de seguimiento deben usarse 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 la memoria disponible para el servidor y para el que la velocidad de creación de nueva entrada 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 procedimientos).

  • Los equipos de gama alta que tienen mucha memoria (por ejemplo, varios casos de soporte técnico recientes implican más de 1 TB de RAM). En estos entornos, el almacén de caché puede crecer de forma grande antes de que experimente cualquier presión de memoria. Esto puede provocar una degradación del rendimiento de cadenas largas de cubos o paseos.

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

  • Vaciar entradas de la TokenAndPermUserStore memoria caché.

Notas:

  1. Para ello, ejecute el siguiente comando:

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Observe el umbral del tamaño de la TokenAndPermUserStore memoria caché 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 la caché es mayor que el umbral observado, ejecute el siguiente comando:

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')