领导节点CPU高的主要原因

Question

我经常看到我们 Redshift 集群的领导节点在 100% CPU 时达到峰值。我已经确定了一个可能的原因：许多并发查询，以及许多领导者要计算的执行计划。这个假设似乎很有可能，因为我们收到最多查询的时间似乎与我们看到的 100% 领先者相同。

为了解决这个问题，我们想知道：是否还有其他可能导致领导者 CPU 高的主要原因？

（我精确的情况是只有领导节点处于高 CPU 并且工作人员看起来很好）

Answer 1

Redshift 领导节点的大小和计算类别与计算节点相同。通常，这意味着领导者对其所扮演的角色进行了过度配置，但由于如果事情变慢，它的角色将非常重要且具有影响力，因此过度配置是件好事。领导者需要编译和优化查询并执行查询中的最终步骤（例如最终排序）。它与会话客户端通信并处理它们的所有请求。如果领导者过载，所有这些活动都会减慢，从而产生严重的性能问题。如果您的领导者 CPU 经常达到 100%，以至于您注意到了，这并不是一件好事。我敢打赌，当这种情况发生时，它看起来会很迟缓。

我见过“领导者滥用”的方式有很多种，当用户之间复制不良模式时，这通常会成为一个问题。排名不分先后：

• 查询中的大数据文字（INSERT ... VALUES ...）。这会将您的数据通过领导节点上的查询编译器。这不是它的设计目的，而且对于领导者来说代价非常昂贵。使用 COPY 命令将数据带入集群。（只是不好，不要这样做）
• 过度使用 COMMIT。提交会导致数据库的一致性状态更新，并且需要运行“提交队列”并为领导者和计算节点创建工作。每隔一个语句都提交 COMMIT 可能会导致该队列备份并正常备份。
• WLM 中定义的插槽过多。Redshift 通常只能同时高效运行 1 到 2 打查询。将总插槽数设置得非常高（例如 50）可能会导致运行效率非常低且 CPU 负载很高。根据工作负载，这可能会显示为计算节点，有时也会显示为引导节点。
• 通过SELECT语句输出大数据。SELECT 返回数据，但当该数据大小为许多 GB 时，该数据移动（和排序）的管理由领导节点完成。如果需要从 Redshift 中提取大量数据，则应使用 UNLOAD 语句来完成。
• 过度使用大光标。光标可能是一个重要的工具，许多 BI 工具都需要它，但光标位于领导者上，过度使用可能会导致领导者对其他任务的注意力减少。
• 许多/大型 UNLOAD 并行关闭。UNLOAD 通常从计算节点直接发送到 S3，但通过“并行关闭”，所有数据都会路由到领导节点，在那里进行组合（排序）并发送到 S3。

虽然上述问题本身都不是问题，但当这些问题被过度使用、以非预期的方式使用或同时出现时，领导者就会开始受到影响。它还取决于您打算对集群做什么 - 如果它支持 BI 工具，那么您可能会有很多游标，但领导者上的这种负载是集群意图的一部分。当集群的目的是为每个人提供一切服务时，经常会出现问题。

如果您的 Redshift 工作负载是领导者函数，并且您正在有效地使用领导者节点（没有大文字，使用 COPY 和 UNLOAD 等），那么高领导者工作负载就是您想要的。您将充分利用关键资源。然而，大多数使用 Redshift 对大数据执行分析，这是计算节点的功能。领导者负担过重可能会严重影响这一使命，需要加以解决。

领导者可能会感到压力的另一种方式是当集群配置有许多较小的节点类型而不是较少的较大节点时。由于领导者与计算节点的大小相同，因此许多较小的节点意味着您有一个小的领导者来完成工作。有一些事情需要考虑，但在投资调整大小之前，我会确保您没有不必要的领导节点压力。