Redshift Auto WLM 配置、队列数和查询槽？

Question

我有一个用例，在 AWS Redshift 的单个数据库中存储了多个客户端表，每个表都有自己单独的架构隔离，以便查询可以在使用自己的单独表时同时运行。我在优先级设置为最高的默认队列上运行它们。

最近我遇到一个案例，其中 1 个查询占用了集群的所有资源，并让所有其他查询停止运行很长时间。此查询执行连接操作并将数据插入到某些表中。 我为解决此问题而实施的一种方法是创建 3 个额外的队列并将一些查询从默认队列重定向到它们，并从查询中的普通视图切换到物化视图。

从文档中我了解到，您最多可以定义 8 个队列，并且每个队列默认有 5 个查询槽（8 个队列中的 40 个）。由于我的大多数查询都是写繁重的（插入、更新和连接）并且有多个模式（超过 30 个），我正在考虑使用 auto-wlm 的所有 8 个队列。

在这种情况下，当只有 1 个查询在优先级设置为最高的队列上运行时，我会感到困惑，它是否能够利用集群的所有可用资源，还是仅占用 1 个可用的内存它正在运行的队列中的插槽？请随时提出您认为有助于实现 auto-wlm 的任何其他方法或为我指明正确的方向（文章、案例研究等）

根据我对文档的理解，请随时指出我可能在上面提出的任何错误解释。

Answer 1

Max Ganz II 很好地解释了 autoWLM 及其局限性，因此我不再赘述。我将谈谈查询性能下降。我花了将近 30 年的时间设计微处理器和高端计算机系统，并在 5 多年的时间里帮助人们使用 Redshift。我以前见过这种情况，您可能无法使用 WLM 设置来改善这种情况，但还是有希望的。

这个问题很可能是由于查询使一个或多个系统资源过载（这是您怀疑的）。但是，数据库只能在边缘工作以限制查询进程使用的资源。 WLM 可以控制 malloc 的卡盘有多大，以便查询可以在更有限的内存占用中运行，但它无法控制查询使用多少内存。 WLM 可以尝试限制查询在 CPU 上运行的时间量，但它实际上并不能控制进程调度程序，操作系统可以。这些 WLM 设置可以使昂贵的查询对其他查询“更友好”，但这些只是围绕边缘进行的调整。

操作系统 (Linux) 控制在硬件上运行的内容，并且硬件有限制。当达到这些限制之一时，系统上的所有工作都会受到影响。所有数据库系统都是如此，不仅仅是 Redshift，而且 Redshift 是建立在高端行业标准硬件集群上的，因此其中一些限制比专门构建的扩展系统更早（还有一些更晚）。需要注意的罪魁祸首是内存、CPU、磁盘 IO 和网络 IO（以及超载的领导节点，这会增加一些夹点）。

很有可能您的查询导致这些硬件系统之一过载并需要重写。两个最常见的原因是将 TB 数据交换到磁盘的高溢出查询和在网络上分布 TB 数据的查询。这两种情况都可能发生在同一个查询中。磁盘 IO 系统和网络 IO 系统的带宽都是有限的，它们的使用由操作系统控制——数据库层无法限制一个查询对它们的使用。

我强烈怀疑您需要查看此查询并查看它正在使用哪些网络和 IO 资源。 （这可能是由于其他方面，但这些是前 2 个。）以下是我用来开始挖掘类似问题的 3 个查询：

-- High network queries
select userid, starttime, query, sum(bytes)/1000000000 as network_gbytes
from stl_dist
where userid <> 1 and starttime > getdate() - interval '1 day'
    group by 1, 2, 3
    having network_gbytes > 10;

-- High spill queries
select userid, starttime, query, sum(bytes)/1000000000 as spill_gbytes
  from stl_scan s
  where perm_table_name ilike '%internal worktable%'
  and userid <> 1 and starttime > getdate() - interval '1 day'
  group by 1, 2, 3
  having spill_gbytes > 10 ;

-- High scan  queries
select userid, starttime, query, sum(bytes)/1000000000 as table_scan_gbytes
  from stl_scan s
  where perm_table_name not ilike '%internal worktable%'
  and userid <> 1 and starttime > getdate() - interval '1 day'
  group by 1, 2, 3
  having table_scan_gbytes > 100;

这些只是过去一天的一般搜索查询，因此您需要调整它们以专注于您的查询并将“有”子句调整到您的集群。