Поделиться через

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

  • Статья

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

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

Симптомы

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

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

  • Использование ЦП для процесса SQL Server больше, чем обычно.

  • При выполнении нерегламентированного запроса вы испытываете снижение производительности. Однако если запрашивать или динамические sys.dm_exec_requests административные представления, результаты не указывают на то, что нерегламентированный запрос ожидает какого-либо sys.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')