槽位使用3 分钟阅读
按分钟统计 BigQuery 槽位使用情况
分钟级槽位使用情况是调试性能问题和了解突发模式的正确粒度。此查询精确显示槽位需求何时激增以及激增持续多长时间。
为什么重要
每小时平均值可能掩盖导致查询排队和性能降级的短暂但密集的槽位突发。分钟级数据揭示这些突发，帮助您确定 Editions 自动扩展器的 max_slots 设置是否足够高以及是否需要调整查询调度。
工作原理
在 MINUTE 粒度上从 JOBS_TIMELINE 汇总 period_slot_ms，除以 60,000（每分钟毫秒数）。日历填充创建连续的逐分钟数据集。
SQL 查询
Fill in your details to get a ready-to-run query:
SQL
-- Average slot consumption per minute (zero-filled)
DECLARE lookback_days INT64 DEFAULT 3;
DECLARE ms_per_min INT64 DEFAULT 60000;
WITH minute_slots AS (
SELECT
TIMESTAMP_TRUNC(period_start, MINUTE) AS minute,
ROUND(SUM(period_slot_ms) / ms_per_min, 2) AS avg_slots
FROM `your-project`.`region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE period_start >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY)
AND statement_type != 'SCRIPT'
GROUP BY minute
),
calendar AS (
SELECT ts AS minute FROM UNNEST(GENERATE_TIMESTAMP_ARRAY(
TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY), MINUTE),
TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), MINUTE),
INTERVAL 1 MINUTE)) AS ts
)
SELECT
c.minute,
IFNULL(m.avg_slots, 0) AS avg_slots
FROM calendar c
LEFT JOIN minute_slots m ON c.minute = m.minute
ORDER BY c.minute将 your-project 和 region-us 替换为您的 GCP 项目和数据集区域。
查询说明
与每小时/每日相同的模式，但在分钟粒度上。ms_per_min 除数为 60,000 ms。注意：对于较长的回溯窗口（>7 天），此查询可能返回大型结果集——对于分钟级分析，减少 lookback_days。
关键洞察
仅持续 1-2 分钟的槽位突发通常是用户的临时查询——考虑设置每用户槽位限制。
持续 10-15 分钟的平台期表明批量管道运行——优化该窗口中最繁重的查询。
如果突发超过 Editions max_slots，查询正在排队——增加 max_slots 或错开工作负载。
将突发时间与 cron/Airflow 调度进行比较，以识别每次突发是哪个管道引起的。
最佳实践
- 1
使用此数据设置 Editions 自动扩展器 max_slots 以覆盖分钟级 P99 需求。
- 2
以分钟粒度分析时，保持 lookback_days 小（1-3 天），以避免大型结果集。
- 3
将突发与并发查询数据交叉参考，以查看同时运行多少查询。
- 4
为持续超过阈值的槽位使用量设置 CloudClerk 警报。