[QUESTION] Finops Utilization report/Server Inventory Status: Darling vs old Full Dashboard #2231

Activity

1. ghauan

   added

   questionFurther information is requestedFurther information is requested

   on Aug 13, 2026
2. erikdarlingdata commented on Aug 13, 2026

   

   erikdarlingdata

   on Aug 13, 2026

   Owner

   More actions

   Good catch, and thank you for running both side by side — that comparison is what made this findable.

   Short answer: it is not history depth. The calculation changed, and Darling's memory term is currently wrong. Your servers are almost certainly right-sized and Darling is mislabeling them.

   What changed

   Both versions apply the same-looking rule:

   p95_cpu > 85 OR memory_ratio > 0.95  →  UNDER_PROVISIONED
   

   But memory_ratio is computed from different source metrics in the two products:

   	numerator	denominator
   Full Dashboard (report.finops_utilization_efficiency)	SUM(pages_kb) from sys.dm_os_memory_clerks	committed_target_kb from sys.dm_os_sys_info
   Darling (UtilizationEfficiencySql)	perfmon Total Server Memory (KB)	perfmon Target Server Memory (KB)

   The old pair compares memory-clerk pages against the committed target, which normally lands comfortably below 1. The new pair is Total vs Target Server Memory — and those two converge to 1.0 by definition on any warmed instance, because Target is the memory SQL Server wants and Total is what it currently holds.

   Measured on a 42-server production fleet running current Darling:

   servers=42   ratio_gt_0.95=42   median=1.0000   min=0.9997   max=1.0002
   

   42 of 42. The memory_ratio > 0.95 term fires on every healthy server, which is exactly what you are seeing.

   Worse, the trigger's direction is wrong for this metric pair: Total ≈ Target means SQL Server has all the memory it asked for — the healthy state. Genuine memory pressure shows up as Total below Target (it wants more than it has), i.e. a ratio under 1. So the rule flags health as starvation.

   Two other differences, for completeness

   • CPU is not the cause. Both use a 24-hour window and a p95 over cpu_utilization_stats, so your CPU verdicts should agree.
   • Darling dropped a trigger. The old view also raises UNDER_PROVISIONED on worker_ratio > 0.8 (worker threads); Darling's rule omits it. So even ignoring memory, the two rules are not equivalent — Darling would miss a genuinely worker-starved server the old dashboard would catch.

   What this means for you right now

   Trust the Full Dashboard's verdict over Darling's for provisioning until this is fixed. Your CPU numbers in the Darling screenshot are the trustworthy half — read p95_cpu_pct directly and ignore the status column. And no, letting Darling accumulate more history will not change it: the memory term uses only the single most recent memory_stats row, so it is independent of how much history you have.

   Tracking the fix in a dedicated bug (linked below) since this needs a decision about what "memory under-provisioned" should actually mean rather than just a threshold tweak.
3. erikdarlingdata

   added a commit that references this issue on Aug 14, 2026

   Fix the two copies review found, and stop the UI inventing a cause

   ...

   ed99cab
4. erikdarlingdata commented on Aug 14, 2026

   

   erikdarlingdata

   on Aug 14, 2026

   Owner

   More actions

   Answered above, and the fix is merged to dev (#2251, #2253) — tracked as #2246.

   To restate the answer now that it is settled: not history depth. The calculation changed when FinOps moved from the SQL views into the apps. The denominators are equivalent (perfmon Target Server Memory is the documented equivalent of committed_target_kb), but the numerator went from memory-clerk pages to all committed server memory — and committed converges on committed-target the moment an instance warms, so the ratio pins at 1.0 and every server trips > 0.95. Measured on 42 servers: median 1.0000, min 0.9997, max 1.0002.

   Your Full Dashboard was right and Darling was wrong. Thank you for running both side by side — that comparison is the only reason this was findable, and it also turned up that Darling had dropped the worker-thread term your old view has always carried.

   Closing since the question is answered and the fix has landed. Note it ships with the next release, so until then the Full Dashboard remains the one to trust for provisioning.
5. erikdarlingdata

   closed this as completedon Aug 14, 2026