I'm trying to reduce Azure Data Explorer costs for several clients by moving clusters to the next smaller engine SKU when CPU utilization is below 45%, cache utilization is below 55%, and both IngestionUtilization and StreamingIngestUtilization are below 45%. My concern is the reported 50% RAM-per-node limit for queries. Is that a hard limit that can cause queries to fail, or would downsizing mainly increase latency? I currently have Reader and Cost Management Reader access, so I may not be able to inspect detailed query memory usage or identify the largest memory-consuming queries.
3 Answers
Average utilization can be misleading. A cluster might average 45% CPU or memory-related utilization while briefly reaching 90–95% during busy periods. Those short spikes may be exactly when users run expensive queries, so downsizing based only on averages could create failures or noticeable performance problems. Review peak and percentile metrics over the busiest periods, not just the overall average, and consider the customer’s service-level expectations before changing the SKU.
The cluster size and current node type matter as well. A smaller SKU may have less memory available per node even if the total cluster capacity looks similar. Since your access is limited, you may need the customer or an administrator to provide query diagnostics, workload details, and peak utilization data. Without that information, a conservative approach is to avoid automatic downsizing and validate the change in a test or maintenance window first.
The 50% RAM figure should be treated as a real per-node query memory limit, not just a latency guideline. Queries involving large joins, summarize operations, or make-series can hit that limit and fail with a memory-related error. A cluster can show low overall CPU and ingestion usage while individual queries still need substantial memory. Before downsizing, test the next smaller SKU against the heaviest production workloads and check both query failures and latency. Query patterns such as shuffle-based joins or aggregations may also reduce memory pressure on a single node.
That’s the part I’m struggling with: I only have Reader and Cost Management Reader access, so I can’t inspect the customer’s memory-heavy queries in detail.