dm_os_memory_cache_clock_hands 理解

Question

正如我在这个问题中提到的，我试图了解时钟指针的工作原理。只需在内存压力时将时钟指针移动，即可移除缓存条目或降低成本。

根据我所学到的，我现在尝试解释dm_os_memory_cache_clock_hands. 当我检查dm_os_memory_cache_clock_hands我的一台服务器（SQL Server 2016 SP1，32 RAM）时，我对我所看到的感到有些困惑。

在round_start_time为CACHESTORE_SQLCP 约为31小时，所以，我觉得，因为它需要一段时间来完成这一轮缓存中没有遭受大量的内存压力。另一方面，我看到last_tick_time每次刷新都会改变，所以手在移动。另一个奇怪的事实是这种removed_all_rounds_count情况也在发生变化。所以条目从缓存中删除。将clock_status始终暂停。在removed_last_round_count大约68000。

所以我的结论是有压力，CACHESTORE_SQLCP因为手在移动、removed_all_rounds_count变化和removed_last_round_count高。
这是对 dmv 的正确解释吗？

我不明白的是为什么round_start_time在 32GB 的服务器上如此之高，而且手一直在移动。

我使用以下脚本（我在Tigertoolbox 中找到的）转换last_tick_time为日期时间：

    declare @ticks_per_ms bigint,@now DATETIME
    select @ticks_per_ms=ms_ticks from sys.dm_os_sys_info
    set @now=getdate()

    CASE WHEN last_tick_time BETWEEN -2147483648 AND 2147483647 AND 
         @ticks_per_ms BETWEEN -2147483648 AND 2147483647 
    THEN DATEADD(ms, last_tick_time - @ticks_per_ms, @now) 
    WHEN last_tick_time/1000 BETWEEN -2147483648 AND 2147483647 AND 
         @ticks_per_ms/1000 BETWEEN -2147483648 AND 2147483647 
    THEN DATEADD(s, (last_tick_time/1000) - (@ticks_per_ms/1000), @now) 
    ELSE NULL 
    END AS last_clock_hand_move

我重新启动了 SQL Server 服务，以便清除 DMV。然后我监控了当地的压力限制和 DMV，看看实际发生了什么。

我不知道我的发现是否正确，但这是我的发现：

• 根据BOL的缓存压力限制CACHESTORE_SQLCP为 5GB（服务器的可见目标内存为 24GB）。因此内部时钟指针应在 5GB (3200MB) 的 62.5% 处触发。
• 我注意到内部指针的状态大约为 3142MB（计算得稍早一点）。这与 BOL 上的信息不符，或者我计算错误。
• removed_all_rounds_countlast_tick_time改变时增加
• 直到达到阈值并再次删除条目之前，手才不再移动。如此重复，直到完成一轮，然后从头开始。
  

Answer 1

SQL Server 中的dm_os_memory_cache_clock_hands动态管理视图(DMV) 用于监视系统中各种内存缓存的时钟指针的状态。时钟指针用于在出现内存压力时管理缓存条目的驱逐。

DMV 中的round_start_time列显示时钟指针当前轮开始的时间。一轮定义为时钟指针完成缓存的完整迭代所需的时间。完成一轮所需的时间越长，缓存上的内存压力就越小。

last_tick_time列显示时钟指针上次移动的时间。如果时钟指针频繁移动，则表明缓存上存在更大的内存压力，并且有更多的缓存条目被逐出。

returned_all_rounds_count列显示自创建缓存以来已从缓存中删除的缓存条目总数。returned_last_round_count 列显示在时钟指针的当前轮期间删除的高速缓存条目的数量。

根据您提供的信息， CACHESTORE_SQLCP缓存可能存在一些内存压力，具体表现为时钟指针频繁移动并且大量缓存条目被删除。在具有 32GB RAM 的服务器上，round_start_time 相对较高的情况并不罕见，因为这可能表明缓存没有承受很大的内存压力，并且能够将大部分条目保留在内存中。

需要注意的是，时钟指针状态可能会因各种原因而暂停，例如在调整缓存大小时或系统负载过重时。这并不一定表明缓存或系统有问题。

为了更好地理解 CACHESTORE_SQLCP 缓存上的内存压力和时钟指针行为的原因，查看其他性能指标和系统活动可能会有所帮助，例如可用内存量、服务器上的工作负载以及总体缓存命中率。查看可能影响缓存或系统的任何最近更改或问题也可能会有所帮助。