为什么我的 Amazon Redshift 查询一直超过我设置的 WLM 超时?

1 分钟阅读
0

我为 Amazon Redshift 查询设置了工作负载管理 (WLM) 超时,但此时段过期后查询还在运行。为什么会发生这种情况?

简短描述

WLM 超时仅适用于查询正在运行阶段的查询。若 WLM 未在预期时间终止查询,通常是因为该查询处于执行以外的阶段。例如,查询可能等待被解析或重写,在锁定状态等待,等待 WLM 队列中的某个点,到达返回阶段,或跳到其他队列。

解决方法

当查询 STV_RECENTS 时,starttime 指的是该查询进入集群的时间,而非该查询开始运行的时间。当查询在 STV_RECENTS 中处于 Running 状态时,它是系统中的实时查询。但在进入 STV_INFLIGHT 状态前,该查询不会使用计算节点资源。如需关于查询计划的更多信息,请参见查询计划和执行工作流程

要查看正在运行的查询的状态,请查询 STV_INFLIGHT,而不是 STV_RECENTS:

select * from STV_INFLIGHT where query = your_query_id;

使用此查询以了解关于查询阶段的更多信息:

select * from SVL_QUERY_REPORT where query = your_query_id ORDER BY segment, step, slice;

使用 STV_EXEC_STATE 表查看计算节点上正在运行的任何查询的当前状态:

select * from STV_EXEC_STATE where query = your_query_id ORDER BY segment, step, slice;

以下是某查询运行时间长于 WLM 超时时段的部分常见原因:

查询处于“返回”阶段

有两个“返回”步骤。检查 STV_EXEC_STATE 以查看查询是否已进入其中一个返回阶段:

  • 从计算节点返回至领导节点
  • 从领导节点返回至客户端

正在回滚

如果某数据操作语言 (DML) 操作发生错误并回滚,则该操作表面上不会停止,因为它正在回滚。您可以通过查询 STV_EXEC_STATE 以查看回滚。如需更多信息,见 STL_UNDONE

查询在运行前花时间排队

查询 STV_WLM_QUERY_STATE 以查看排队时间:

select * from STV_WLM_QUERY_STATE where query = your_query_id;

查询在锁定状态等待

如果查询在 STV_RECENTS 中可见,但在 STV_WLM_QUERY_STATE 中不可见,可能是查询正在锁定状态等待,而未进入队列。有关检查是否锁定的更多信息,请参阅如何在 Amazon Redshift 中检测和释放锁定?

查询跳到其他队列

如果某读取查询达到其当前 WLM 队列的超时限制,或者如果有指定跳转操作的查询监控规则,则该查询会被推送到下一个 WLM 队列。要确认查询是否跳到下一个队列:

要防止查询跳到其他队列,请配置 WLM 队列WLM 查询监控规则。如需关于队列跳转的更多信息,请参见 WLM 查询队列跳转

网络或防火墙问题

如果 Amazon Redshift 服务器在与您的客户端通信时遇到问题,服务器可能会卡在“return to client”状态。检查与网络组件的冲突,如入站本地防火墙设置、出站安全组规则,或出站网络访问控制列表(网络 ACL)规则。如需更多信息,见请参见从 Amazon EC2 外部进行连接 — 防火墙超时问题

集群问题

集群本身的问题,如硬件问题,可能导致查询冻结。在这种情况下,集群处于“hardware-failure”状态。要恢复一个单节点集群,请从快照还原集群。在多节点集群中,故障节点会被自动替换。


相关信息

优化查询性能

分析和改进查询

AWS 官方
AWS 官方已更新 3 年前