Выполнение запросов занимает больше времени, когда размер кэша TokenAndPermUserStore увеличивается в SQL Server

  • Статья

Эта статья поможет устранить проблемы, связанные с производительностью запросов при росте размера TokenAndPermUserStore . Он также предоставляет различные причины и обходные пути.

Исходный номер базы знаний: 927396

Симптомы

В Microsoft SQL Server возникают следующие симптомы:

  • Выполнение запросов, которые обычно выполняются быстро, занимает больше времени.

  • Загрузка ЦП для процесса SQL Server выше, чем обычно.

  • При выполнении нерегламентированного запроса производительность снижается. Однако при запросе динамических sys.dm_exec_requestssys.dm_os_waiting_tasks административных представлений результаты не указывают на то, что нерегламентированный запрос ожидает какой-либо ресурс.

  • Размер кэша TokenAndPermUserStore постоянно увеличивается.

  • Размер кэша TokenAndPermUserStore составляет несколько сотен мегабайт (МБ).

  • В некоторых случаях выполнение DBCC FREEPROCCACHE команды или DBCC FREESYSTEMCACHE обеспечивает временное облегчение.

Причина

Проблемы с производительностью, такие как высокий объем ЦП и увеличенное использование памяти, могут быть вызваны чрезмерными записями в TokenAndPermUserStore кэше. По умолчанию записи в этом кэше очищаются только в том случае, если SQL Server сигнализирует о нехватке внутренней памяти. На серверах с большим объемом ОЗУ внутренняя нехватка памяти может вызываться нечасто. Когда этот кэш увеличивается, поиск существующих записей для повторного использования занимает больше времени. Доступ к этому кэшу управляется спин-блокировкой. Поиск может выполняться только по одному потоку за раз. Это в конечном итоге приводит к снижению производительности запросов и повышению загрузки ЦП.

Чтобы отслеживать размер кэша TokenAndPermUserStore , можно использовать запрос, похожий на следующий:

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

Кэш TokenAndPermUserStore поддерживает следующие типы маркеров безопасности:

  • LoginToken
    • Один маркер входа для каждого участника уровня сервера.
  • TokenPerm
    • Записывает все разрешения для защищаемого объекта для Объектов UserToken и SecContextToken.
    • Каждая запись в этом кэше является одним разрешением на определенный защищаемый объект. Например, разрешение на выбор, предоставленное для таблицы t1 пользователю u1.
    • Эта запись маркера отличается от записей в кэше результатов проверки доступа (ACR). Записи ACR в основном указывают, имеет ли пользователь или имя входа разрешение на выполнение всего запроса.
  • UserToken
    • Один маркер пользователя для каждой базы данных для входа.
    • Хранит сведения о членстве в ролях уровня базы данных.
  • SecContextToken
    • Для каждого субъекта уровня сервера создается один элемент SecContextToken.
    • Сохраняет контекст безопасности на уровне сервера для субъекта.
    • Содержит кэш хэш-таблицы маркеров пользователей.
    • Хранит сведения о членстве в ролях уровня сервера.
  • TokenAccessResult
    • Существуют различные классы записей TokenAccessResult.
    • Проверка доступа указывает, имеет ли пользователь в конкретной базе данных разрешение на выполнение запроса, включающего несколько объектов.
    • До microsoft SQL Server 2008 кэши безопасности ACR хранились в одном кэше , TokenAndPermUserStore.
    • В SQL Server 2008 году кэши ACR были разделены, а записи кэша ACR отслеживались в собственных хранилищах отдельных пользователей. Это разделение повысило производительность и обеспечило лучшее количество контейнеров и контроль квот для кэшей.
    • В настоящее TokenAndPermUserStore время и ACRCacheStores являются единственными типами кэша безопасности, которые используются. Дополнительные сведения о кэшах ACR см. в разделе Параметры конфигурации сервера проверка кэша доступа.

Чтобы получить сведения о различных кэшах и их отдельных размерах, можно выполнить следующий запрос:

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

Вы можете выполнить следующий запрос, чтобы определить типы маркеров, которые растут в :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

Обходной путь

SQL Server предлагает два флага трассировки, которые можно использовать для настройки квоты TokenAndPermUserStore объекта (по умолчанию квота отсутствует. Это означает, что в этом кэше может быть любое количество записей).

  • TF 4618 — ограничивает число записей в TokenAndPermUserStore 1024.
  • TF 4618+TF 4610 — ограничивает количество записей в TokenAndPermUserStore 8192.

Если очень низкое число входов 4618 вызывает другие проблемы с производительностью, используйте traceflags 4610 и 4618 вместе.

Флаги трассировки 4610 и 4618 описаны в разделе электронной документации DBCCC TRACEON — флаги трассировки.

Эти флаги трассировки следует использовать для сценариев, в которых неограниченный TokenAndPermUserStore рост слишком велик для сервера. Обычно это происходит в двух типах сред:

  • Низкоуровневое или среднее оборудование, для которого TokenAndPermUserStore занимает большой объем доступной памяти для сервера и для которого скорость создания новых записей происходит быстрее или так же быстро, как скорость вытеснения кэша. Это может привести к состязанию в памяти и более частому признанию кэша недействительным для других частей сервера (например, кэша proc).

  • Высокопроизводительные компьютеры с большим объемом памяти (например, несколько недавних вариантов поддержки включали более 1 ТБ ОЗУ). В этих средах хранилище кэша может увеличиться, прежде чем оно испытает нехватку памяти. Это может привести к снижению производительности из-за длинных цепочек контейнеров или прогулок.

В качестве временного устранения рисков этот кэш можно периодически очищать с помощью следующего метода:

  • Очистка записей из кэша TokenAndPermUserStore .

Примечания.

  1. Для этого выполните следующую команду.

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Наблюдайте за пороговым значением размера кэша TokenAndPermUserStore при появлении проблем.

  3. Создайте запланированное агент SQL Server задание, которое выполняет следующие действия:

    • Проверьте размер кэша TokenAndPermUserStore . Чтобы проверка размер, выполните следующую команду:

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

    • Если размер кэша превышает наблюдаемое пороговое значение, выполните следующую команду:

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')