As consultas demoram mais para serem concluídas quando o tamanho do cache TokenAndPermUserStore aumenta em SQL Server

Este artigo ajuda você a solucionar problemas relacionados ao desempenho da consulta quando o tamanho do TokenAndPermUserStore aumenta. Ele também fornece várias causas e soluções alternativas.

Número de KB original: 927396

Sintomas

No Microsoft SQL Server, você experimenta os seguintes sintomas:

• Consultas que normalmente são executadas rapidamente levam mais tempo para serem concluídas.

• O uso da CPU para o processo de SQL Server é maior do que o normal.

• Você experimenta um desempenho reduzido ao executar uma consulta ad hoc. No entanto, se você consultar as sys.dm_exec_requests exibições de gerenciamento dinâmico ou sys.dm_os_waiting_tasks , os resultados não indicarão que a consulta ad hoc está aguardando por qualquer recurso.

• O tamanho do cache cresce a TokenAndPermUserStore uma taxa constante.

• O tamanho do TokenAndPermUserStore cache é de várias centenas de megabytes (MB).

• Em alguns casos, executar o DBCC FREEPROCCACHE comando ou DBCC FREESYSTEMCACHE fornece alívio temporário.

Motivo

Problemas de desempenho, como alta CPU e aumento do uso de memória, podem ser causados por entradas excessivas no TokenAndPermUserStore cache. Por padrão, as entradas nesse cache são limpas somente quando SQL Server sinaliza a pressão de memória interna. Em servidores que têm muita RAM, a pressão de memória interna pode não disparar com frequência. Quando esse cache cresce, leva mais tempo para pesquisar entradas existentes para reutilizar. O acesso a esse cache é controlado por um spinlock. Somente um thread por vez pode fazer a pesquisa. Esse comportamento eventualmente faz com que o desempenho da consulta diminua e mais uso de CPU ocorra.

Para monitorar o tamanho do TokenAndPermUserStore cache, você pode usar uma consulta que se assemelha à seguinte consulta:

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

O TokenAndPermUserStore cache mantém os seguintes tipos de token de segurança:

• LoginToken
  • Um token de logon por entidade de nível de servidor.
• TokenPerm
  • Registra todas as permissões de um objeto securcável para um UserToken e SecContextToken.
  • Cada entrada nesse cache é uma única permissão em um securable específico. Por exemplo, uma permissão de seleção concedida na tabela t1 para usuário u1.
  • Essa entrada de token é diferente das entradas no cache do ACR (Access Check Results). As entradas do ACR indicam principalmente se um usuário ou logon tem permissão para executar uma consulta inteira.
• Usertoken
  • Um token de usuário por banco de dados para um logon.
  • Armazena informações sobre associação em funções de nível de banco de dados.
• SecContextToken
  • Um SecContextToken criado por entidade de nível de servidor.
  • Armazena o contexto de segurança em todo o servidor para uma entidade de segurança.
  • Contém um cache de tabela de hash de Tokens de Usuário.
  • Armazena informações sobre a associação em funções de nível de servidor.
• TokenAccessResult
  • Diferentes classes de entradas TokenAccessResult estão presentes.
  • A Verificação de Acesso indica se um determinado usuário em um determinado banco de dados tem permissão para executar uma consulta que envolve vários objetos.
  • Antes do Microsoft SQL Server 2008, os caches de segurança do ACR eram armazenados em um único cache, TokenAndPermUserStore.
  • Em SQL Server 2008, os caches ACR foram separados e as entradas de cache do ACR foram rastreadas em seus próprios repositórios de usuários individuais. Essa separação melhorou o desempenho e forneceu melhor contagem de buckets e controle de cota para os caches.
  • Atualmente, TokenAndPermUserStore e ACRCacheStores são os únicos tipos de cache de segurança que são usados. Para obter mais informações sobre caches ACR, confira Acessar marcar cache Opções de configuração do servidor.

Você pode executar a consulta a seguir para obter informações sobre os diferentes caches e seus tamanhos individuais:

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

Você pode executar a consulta a seguir para identificar os tipos de tokens que estão crescendo no 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

Solução alternativa

SQL Server oferece dois sinalizadores de rastreamento que podem ser usados para configurar a cota do TokenAndPermUserStore (por padrão, não há cota. Isso implica que pode haver várias entradas neste cache).

• TF 4618 – Limita o número de entradas para TokenAndPermUserStore 1024.
• TF 4618+TF 4610 – Limita o número de entradas em TokenAndPermUserStore 8192.

Se a contagem de entradas muito baixa de 4618 causar outras preocupações de desempenho, use as traceflags 4610 e 4618 juntas.

Os sinalizadores de rastreamento 4610 e 4618 estão documentados no tópico Books Online, DBCCC TRACEON – Trace Flags.

Esses sinalizadores de rastreamento devem ser usados para cenários em que o crescimento não TokenAndPermUserStore vinculado é muito grande para o servidor. Normalmente, isso ocorre em dois tipos de ambientes:

• Hardware low-end ou médio para o qual TokenAndPermUserStore ocupa uma grande quantidade da memória disponível para o servidor e para o qual a taxa de nova criação de entrada é mais rápida ou tão rápida quanto a taxa de despejo de cache. Isso pode causar contenção de memória e invalidação de cache mais frequente para outras partes do servidor (por exemplo, cache proc).

• Computadores high-end que têm muita memória (por exemplo, vários casos de suporte recentes envolveram mais de 1 TB de RAM). Nesses ambientes, o repositório de cache pode crescer muito antes de sofrer qualquer pressão de memória. Isso pode causar degradação de desempenho de cadeias de balde longas ou caminhadas.

Como mitigação temporária, você pode limpar esse cache periodicamente usando o seguinte método:

• Liberar entradas do TokenAndPermUserStore cache.

Observações:

1. Para fazer isso, execute o seguinte comando:

   DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

2. Observe o limite do tamanho do TokenAndPermUserStore cache quando os problemas começam a aparecer.

3. Crie um trabalho de SQL Server Agent agendado que execute as seguintes ações:

   • Verifique o tamanho do TokenAndPermUserStore cache. Para marcar o tamanho, execute o seguinte comando:

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

   • Se o tamanho do cache for maior que o limite observado, execute o seguinte comando:

     DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')