Выполнение запросов занимает больше времени, когда размер кэша 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
.
Примечания.
Для этого выполните следующую команду.
DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
Наблюдайте за пороговым значением размера кэша
TokenAndPermUserStore
при появлении проблем.Создайте запланированное агент SQL Server задание, которое выполняет следующие действия:
Проверьте размер кэша
TokenAndPermUserStore
. Чтобы проверка размер, выполните следующую команду:SELECT SUM(pages_kb) AS "CurrentSizeOfTokenCache(kb)" FROM sys.dm_os_memory_clerks WHERE name = 'TokenAndPermUserStore'
Если размер кэша превышает наблюдаемое пороговое значение, выполните следующую команду:
DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')