Eighty-two percent average and still slow
Northwind runs its analytics platform on an F32 capacity. Overnight, 60 notebooks execute between 00:00 and 04:00, each taking about 20 minutes, with up to three concurrent; each recomputes aggregates by reading a 2 TB unpartitioned Delta table in full. Capacity Metrics reports 82% average utilization over 24 hours with 190% peaks lasting 20 minutes twice nightly. Users of a Direct Lake semantic model complain it is slow at 06:00 and again at 13:00, and 12% of pipeline runs fail with an operation-timeout message after 60 minutes.
Finance has one non-negotiable condition: yesterday's numbers must not change.
1. Eighty-two percent average looks like headroom. Explain why users still see slowdowns, grounded in how Fabric evaluates consumption.
Read the worked answer
Fabric does not budget on a daily average. It evaluates consumption continuously against the capacity and smooths cumulative usage over a 24-hour window. Sustained consumption above the SKU for roughly ten minutes begins delaying interactive operations; sustained longer, interactive requests are rejected; background operations are rejected at the far end of the curve. Separately, the smoothing mechanism means a burst is not free - the debt is carried forward and deducted from later windows.
So the two numbers describe different things. 82% is the smoothed daily picture. 190% for 20 minutes is the actual contract with the engine, and users feel the contract. Three notebooks launching concurrently against a 2 TB table can saturate an F32 within seconds.
The 06:00 slowness is most likely carryover from the 04:00 peak. The 13:00 slowness is most likely an interactive peak that coincides with residual debt plus a mid-day refresh. Both should be confirmed in the metrics app by looking at the timepoint view and the throttling/carryover sections rather than the daily summary, and by identifying the top-consuming item in each window.
2. Reduce the 190% peak without changing the reported numbers. What do you change first, and what do you deliberately not change?
Read the worked answer
Change the read path, not the logic. The 2 TB table is unpartitioned, so every run scans everything to recompute aggregates that change only in a narrow date range. Partition the table by business date, add a watermark so each notebook computes only the partitions whose source data changed since the last successful run, and MERGE the result into the aggregate table. Byte-identical aggregation SQL, identical output, a fraction of the I/O - which is what the CU spike actually measures.
Two supporting moves: consolidate the 60 notebooks so three concurrent full scans become one scheduled chain, and spread any remaining independent jobs across the four-hour window instead of launching them together.
Deliberately do not change: the aggregation expressions, the grain of the aggregate table, or the semantic model's measures. Finance's condition is about reproducibility of published numbers; touching the transformation logic converts a performance change into a restatement and a reconciliation exercise. Also do not paper over the peak by buying capacity first - that is the expensive way to keep an inefficient scan.
3. Twelve percent of runs fail after 60 minutes. What do you investigate, and how do you make future failures visible before users notice?
Read the worked answer
First separate the two possible failure families, because the remediation differs:
- Genuine compute failure - shuffle spill, executor loss, a skew in the partition key. Evidence: Spark stage metrics, spill-to-disk counters, task-duration distribution.
- Capacity starvation - the run does not fail, it stops making progress while the capacity is throttled and then trips the timeout. Evidence: plot the failure timestamps against the metrics app; failures clustering at 02:00–04:00 and again with the 13:00 slowdown is the signature.
The 60-minute figure matching a round timeout, combined with the known 190% peaks, points at starvation first. Fix the peak and the failure rate usually collapses without touching the notebook.
Making it visible: emit job and activity events to a workspace-monitoring Eventhouse, build a small KQL query for failed and long-running runs, and put an Activator alert on it that fires to the owning team's channel. Add an expected-duration check to the pipeline itself - if the aggregate table has not been refreshed by 05:30, fail the pipeline loudly rather than letting stale-but-plausible numbers reach finance.