领导节点CPU高的主要原因答案

【问题标题】：Main causes for leader node to be at high CPU领导节点CPU高的主要原因
【发布时间】：2019-10-14 08:19:24
【问题描述】：

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

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

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

【问题讨论】：

面临同样的问题，无法解决。最后一个选项是增加集群中的节点。
我最近也遇到过，一些查询正在执行，然后从客户端中止，我无法终止它们。但是，我不清楚领导节点是在查询执行期间还是在中止之后达到 100。

标签： amazon-web-services amazon-redshift

【解决方案1】：

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

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

查询中的大数据文字（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 对大数据执行分析，这是计算节点的功能。一个高负荷的领导者可能会大大减损这项任务，需要加以解决。

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

【讨论】：

【解决方案2】：

每当您在领导节点上执行一些需要计算的命令时，无论是用于调度数据、计算统计数据还是从工作人员那里聚合结果，例如 COPY、UNLOAD、VACUUM、ANALYZE，您都会看到 CPU 使用率增加。更多信息请点击此处：https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html

【讨论】：