调整Snowflake Large仓库max_concurrency_level后排队问题加剧求助

• 仓库资源碎片化：Large规格仓库的每个节点有固定计算资源（vCPU、内存等），当max_concurrency_level从24调至32时，单查询可分配的资源被进一步稀释。若你的仪表板查询属于CPU/内存密集型，单个查询的执行时间会拉长，占用队列的时间更久，导致后续查询排队累积。
• 并发调度阈值冲突：Snowflake的并发控制基于仓库节点资源使用率调度。调高并发上限后，更多查询会被同时放入执行队列，但仓库总处理能力并未提升（仍为Large规格），一旦节点资源饱和，新查询会直接进入排队；而24并发时，较低的阈值可能让部分查询延迟调度，反而避免了瞬间资源耗尽引发的大规模排队。
• 查询优先级抢占：若仪表板存在不同优先级的查询，调高并发后低优先级查询可能抢占高优先级查询的资源，导致高优先级查询执行变慢，整体队列周转效率下降。可检查QUERY_TAG或已设置的资源优先级规则是否正常生效。
• 缓存失效叠加影响：五月初调整参数时，可能恰好遇到仓库缓存失效（如仓库重启、缓存数据过期），大量查询需重新计算。此时调高并发数会让更多查询同时触发冷计算，进一步拖慢整体执行速度，加剧排队。可通过QUERY_HISTORY查看缓存命中率的变化。

排查建议 #

• 对比参数调整前后的单查询平均执行时间、资源使用率（CPU、内存），用以下语句分析：

  SELECT * FROM TABLE(WAREHOUSE_METERING_HISTORY(WAREHOUSE_NAME => '你的仓库名', START_TIME => DATEADD('day', -14, CURRENT_TIMESTAMP())));
  SELECT * FROM TABLE(QUERY_HISTORY(WAREHOUSE_NAME => '你的仓库名', START_TIME => DATEADD('day', -14, CURRENT_TIMESTAMP())));
  

• 临时将max_concurrency_level调回24，观察排队情况是否缓解，确认参数调整为直接诱因。
• 检查仓库是否开启自动缩放（Auto-scaling），高并发可能触发频繁的节点增减，带来额外调度开销。

内容的提问来源于stack exchange，提问作者user21038394