Paramètres de la semaine: access check cache bucket count, access check cache quota

Lundi, septembre 10, 2012
By David Baffaleuf in SQL Server (dbaffaleuf@capdata-osmozium.com) [71 article(s)]

Pour cette nouvelle série d’articles, on se propose d’évoquer les paramètres configuration un peu obscurs de SQL Server. Cette semaine, on prend la liste par le haut : access check cache bucket count & access check cache quota

Historique:

Ces deux paramètres trouvent leur origine dans un problème de surconsommation d’un user store en SQL Server 20005 RTM et SP1, en l’occurrence TokenAndPermUserStore. Ce dernier a été ajouté lors des grandes manœuvres de refonte de la gestion mémoire de 2005 pour permettre de conserver en cache les derniers checks de permissions sur les objets, avec un quota par défaut sans limite sinon par la mémoire physique. Dans les premiers builds de la 2005 x64, sur de grosses plateformes avec beaucoup d’utilisateurs différents exécutant beaucoup de requêtes ad-hoc, on constatait que ce user store avait tendance à grossir rapidement dans sys.dm_os_memory_clerks / sys.dm_os_memory_cache_entries.

Afin de contourner le problème, deux traceflags avaient été ajoutés en SQL 2005 SP2 (TF4610 /TF4618) et SP3 (TF4621) pour fixer le nombre d’entrées maximum dans le TokenAndPermUserStore. Et à la sortie de SQL Server 2008, deux nouveaux paramètres de configuration: access check cache bucket count et access check cache quota.

Utilisation:

Chaque paramètre est dynamique est possède une valeur par défaut qui est établie en fonction de l’architecture:

select name, value, minimum, maximum, value_in_use, is_dynamic 
from sys.configurations 
where name in ('access check cache bucket count','access check cache quota') 

name 				value 	minimum maximum 	value_in_use is_dynamic 
------------------------------- ------- ------- --------------- -------------- ------------- 
access check cache bucket count 0 	0 	16384 		0 		1 
access check cache quota 	0 	0 	2147483647 	0 		1

- access check cache bucket count limite le nombre de hash buckets utilisés pour localiser les entrées dans le cache. Sur x86, la valeur par défaut est de 256, et sur x64, la valeur est de 2048 hash buckets.

Chaque bucket sert à stocker une à plusieurs entrées. Le même principe est utilisé dans de nombreux CACHESTOREs et USERSTOREs dans SQL Server (par exemple CACHESTORE_SQLCP, CACHESTORE_OBJCP, USERSTORE_DBMETADATA, etc… ). Dans le cas de TokenAndPermUserStore, les entrées peuvent être de plusieurs types: LoginToken, SecContextToken, TokenAccessResult, TokenPerm, UserToken… et chaque type possède différentes classes et sous- classes. La répartition de ces classes est visible dans sys.dm_os_memory_cache_entries:

SELECT COUNT(*) as TokenCount, *
FROM
(SELECT
       x.value('(//@name)[1]', 'varchar (100)') AS [Token Name],
       x.value('(//@class)[1]', 'bigint') AS [Class],
       x.value('(//@subclass)[1]', 'int') AS [SubClass]
FROM

      (SELECT CAST (entry_data as xml)
       FROM sys.dm_os_memory_cache_entries
       WHERE type = 'USERSTORE_TOKENPERM')
              AS R(x)
       ) a GROUP BY [Token Name],[Class],[SubClass]

TokenCount	Token Name		Class	SubClass
--------------- ----------------------- ------- ---------
14		LoginToken		21	0
30		SecContextToken		21	0
42		TokenAccessResult	0	22
16		TokenAccessResult	1	2
1860		TokenAccessResult	1	22
20		TokenAccessResult	19	22
8		TokenAccessResult	20	22
129		TokenAccessResult	65535	0
38		TokenPerm		0	22
1976		TokenPerm		1	2
11		TokenPerm		19	22
8		TokenPerm		20	22
149		UserToken		7	0

Chaque type d’entrée gère un besoin différent. Les entrées de type TokenAccessResult gèrent le contrôle des permissions cumulées sur les objets notamment pour les jointures (cf KB).

- access check cache quota limite quant à lui  le nombre d’entrées pour tout le cache. Sur x86, le nombre d’entrées est limité à 2048 et sur x64 à 8192.

Vous ne devriez pas avoir à modifier ces valeurs par défaut sauf sur l’avis du support.

A suivre un autre paramètre obscur…

A+ David B.

Référence:

- http://support.microsoft.com/default.aspx?scid=kb;EN-US;959823
- http://blogs.msdn.com/b/psssql/archive/2008/06/16/query-performance-issues-associated-with-a-large-sized-security-cache.aspx
- http://support.microsoft.com/kb/955644/en-us

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags:

Leave a Reply