每小时运行一次 DBCC FREESYSTEMCACHE ('TokenAndPermUserStore') 有什么缺点？

Question

我在我们的一台生产服务器上的 SQL Server 内存缓存中看到了一些令人担忧的行为。我们使用的是 SQL Server 2014 SP2 企业版，16 核，400GB RAM（300GB 专用于 SQL Server）。

使用此查询（归功于Glenn Berry）：

SELECT TOP(10) mc.[type] AS [Memory Clerk Type], 
       CAST((SUM(mc.pages_kb)/1024.0) AS DECIMAL (15,2)) AS [Memory Usage (MB)] 
FROM sys.dm_os_memory_clerks AS mc WITH (NOLOCK)
GROUP BY mc.[type]  
ORDER BY SUM(mc.pages_kb) DESC OPTION (RECOMPILE);

我发现了一个问题。这些USERSTORE_TOKENPERM值增长到似乎超过缓存的程度，因此，几乎所有计划都被编译并且没有被缓存。也就是说CACHESTORE_SQLCP，CACHESTORE_OBJCP每个大约 200 MB，而USERSTORE_TOKENPERM缓存高达 11 GB。存储了超过 168,000 个令牌，大约有 100 个并发/600 个用户，连接数为 3000-5000。这些数字似乎相差甚远。

不幸的是，提供此应用程序的供应商没有“系统要求”文档之类的疯狂内容，并且他们不会承诺在未经测试的 Service Pack/CU 上支持该应用程序。所以我的手被束缚在 SQL Server 2014 SP2 上，因为我读过的其他线程建议升级到 SQL Server 2014 SP2 CU7 或更高版本。这是长期目标。所以我需要另一个短期解决方案。

从 2009 年开始运行此线程中建议的命令后。

具体来说：

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

我看到我们的 CPU 使用率从 30%-80% 的使用率下降到 30% 以下。用户对应用程序“缓慢”的抱怨已经减弱。计划缓存现在增长到 10 GB 或更多。

随着时间的推移，令牌缓存再次增长。接近一天结束时，我们开始再次看到有问题的缓存行为。我已安排DBCC命令每晚在工作时间之外运行。

我知道我可以在这里应用跟踪标志 4610 和 4618来限制存储令牌的数量。

将存储缓存条目的哈希表的大小增加 8 倍。与跟踪标志 4618 一起使用时，会将 TokenAndPermUserStore 缓存存储中的条目数增加到 8,192。

到一天结束时，我们最终缓存了大约 40,000 个令牌。

有没有人对此问题有任何经验（或知识）可以说明使用跟踪标志或清除缓存是否是更有效的解决方案？

比每天一次更频繁地清除 TokenAndPermUserStore 缓存有什么缺点？说，每小时？有没有“太频繁”？

通过跟踪标志限制令牌缓存的缺点是什么？最终用户是否会因令牌限制或其他原因（从而导致另一个问题）而遇到瓶颈？

我在这里主要担心的是，这是医疗数据，我不想因为与缓存刷新相关的问题而丢失患者数据。

Answer 1

来自评论：

这听起来像是微软产品支持工程师的主要候选人。——马克斯·弗农

我们遇到了同样的问题，我们的最终决定是DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')每天使用。我们认为该解决方案比使用跟踪标志更可预测和更易于管理。不幸的是，微软未能找到并提供更好的解决方案。——丹尼斯·鲁巴什金

这是一个老错误，我有预感最新的 SP/CU 应该修复它。如果没有，您可能需要联系 MS 支持。至于问题，我在 SQL Server 2008 R2 版本中经常遇到这个问题，并且有选择地清除缓存并没有导致任何问题。-香基