From the evening of September 27 to the morning of September 30 (UTC), customers in the Azure West Europe region experienced slow queries and timeouts. Writes were accepted throughout, but on some partitions, new data was not immediately queryable. Earlier incidents on this cluster (September 7, 11, 15 and 16) produced the same symptom with different triggers and have their own RCAs. We believe the condition described herein was the root cause of all prior incidents.
All data in the cluster is stored on redundant pods across many physical nodes. These pods read time-series data through memory-mapped files. The host’s operating system keeps the most frequently accessed parts of those files in a page cache built from memory not consumed by the pods themselves. In this region, each pod holds about 365 GB of data. The cache on a host could not hold the data its pods were querying, so reads that would normally come from cache became page faults served from disk. Each pod read about 90 MB/s from disk, thus a host with ten pods reached roughly 990 MB/s, which is near the throughput ceiling on each host.
Memory consumption looked normal on every metric we monitor. The storage process itself uses little memory, and the cache takes the remainder, so a shortage would not appear as memory pressure or shortfall. At the throughput ceiling, index lookups on the write path were delayed by disk reads, causing writes to fall behind and pods to fail their replication-lag health check. Pods in this region spent 8.9% of the day past the lag threshold, against 0.09% in a comparable region. At peak, both replicas of the busiest partitions fell behind together, creating access delays which were most acutely visible through the query path.
Slow disk caused health and readiness checks to time out, so healthy pods were removed from rotation and restarted. Each restart took 30 to 85 minutes to recover, during which the pod's partner carried the load alone, with the rebuild adding even more disk load. A file-reference safeguard was also causing 50+ pod restarts a day where a normal rate would be 0.
While early changes helped, and resolved many trouble indicators, they did not solve the root cause. We doubled query-layer capacity, restarted pods, raised the readiness timeouts, raised cleanup timeouts to avoid safeguard restarts, and doubled recovery concurrency after a restart. We ruled out a controller lock, a per-disk limit, and a single tenant's load.
The root cause fix was to raise each storage pod's resource request so that each host holds fewer pods. Each pod now has twice as much memory for page cache and disk throughput. Within 1 hour of this change, query abandonment fell from 31% to 0.1%. Page faults and disk reads dropped sharply. During the next morning's peak, abandonment was 0.06%, within normal limits.
Sep 27 22:58 - Query queue depth alert fires; incident opened. Query-layer capacity increased over the next hours without lasting effect
Sep 28 07:00 - Degradation at morning peak; storage pods fall behind on writes and fail health checks; stuck pods restarted one at a time
Sep 28 11:33 - Restart loop identified: slow disk causes health checks to trigger restart; each restart takes 30 to 85 minutes to recover
Sep 28 13:45 - Lost file-reference cleanup identified as a second source of forced restarts
Sep 29 08:58 - Readiness probe timeout raised and rolled out fleet-wide
Sep 29 11:10 - Throughput appears to recover; degradation returns, with 36% of queries abandoned
Sep 29 16:20 - Queue clears after recovery-concurrency and probe changes
Sep 30 00:25 - Cleanup timeout raised to 24 hours; forced restarts stop
Sep 30 07:00 - Degradation at peak; abandonment about 55%
Sep 30 11:59 - Analysis shows cache capacity per pod is too small and disk reads are at the host ceiling
Sep 30 12:43 - Rollout begins to spread pods across more nodes
Sep 30 13:21 - Query performance returns to normal; abandonment down to 0.1% within the hour
Sep 30 14:20 - Page faults and disk reads confirmed sharply lower after rollout
Oct 1 07:00 to 09:00 - Morning peak with 0.06% abandonment versus 40% to 55% the day before
Oct 1 09:48 - Incident declared resolved internally
We added warning alerts for page-fault rate, cache coverage, disk reads on storage volumes, and query abandonment. Each alert is designed so that cache pressure appears before causing external visibility. Runbooks now suggest major page faults as a leading indicator of storage performance degradation, with details on “relief valves” available to tune. We are continuing to track down the storage-engine reference leak and moving the disk check out of the health path. Neither leak nor check is a risk factor for triggering this type of incident; they are conditions observed during diagnosis and remediation that warrant investigation.