Redshift WLM 配置：如何使用未分配的内存？

Question

当您定义 Redshift 查询队列时，您可以分配分配给每个队列的内存比例。例如，如果您有 5 个队列，您可能会为每个队列分配 20% 的内存。但是，您也允许分配内存，使其一部分保持未分配状态。

在本文档中： http://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html 它说， “任何未分配的内存都由 Amazon Redshift 管理，如果队列请求额外的内存进行处理，则可以将其临时分配给队列。 例如，如果您配置四个队列，您可以按如下方式分配内存：20%、30%、15%、15%。剩余的 20% 未分配并由服务管理。”

在文档的前面，它说， “如果特定查询需要的内存多于分配给单个查询槽的内存，则可以通过增加 wlm_query_slot_count 参数来增加可用内存。以下示例将 wlm_query_slot_count 设置为 10，执行真空，然后将 wlm_query_slot_count 重置为 1。”

这与内存分配有关吗？可以使用查询槽计数调整来临时消耗比整个队列通常允许的更多的内存吗？

我认为我的问题实际上是关于第一句话的这一部分，“任何未分配的内存都由 Amazon Redshift 管理，并且可以临时分配给队列如果队列请求额外的内存进行处理。 "

这是否意味着运行查询的用户必须专门请求额外的内存？这是否意味着除非您提出这些特定请求，否则保留一些未分配的内存是没有用的？

Answer 1

wlm_query_slot_count 和队列的内存分配这两个概念是不同的。

例如，当您将集群的并发级别分配为 20 时，您将创建 20 个执行槽。如果这些较小的槽（与默认较大的 5 个槽相比）对于某些查询（例如 VACUUM 或更大的报告）来说太小了，您可以使用 wlm_query_slot_count 为这些特定查询提供多个槽而不是单个槽。

在 CPU、IO 和 RAM 方面对各种插槽的资源分配不必是统一的，因为您可以给某些队列比其他队列更多的内存，因为发送到该队列的查询需要更多内存。当您看到更多查询在计算期间内存不足时溢出到磁盘时，您可以知道需要更多内存。

对于您正在运行的每个查询，Redshift 将根据您正在访问的列以及您在这些列上应用的函数来估计内存需求（这是使用尽可能窄的列定义的另一个好理由） .如果 WLM 有未分配的内存，它可以将其中的一部分提供给需要它的查询。

尽管如此，当您创建此类队列定义时，您缺少集群灵活性以将资源分配给查询。例如，您可能会创建一个完全堵塞的队列，而其他队列处于空闲状态并浪费集群资源。因此，请谨慎操作，并监控这些队列的使用情况，以验证您是否确实在提高集群优先级和性能，而不是损害它。

Answer 2

简短的回答是 - wlm_query_slot_count 和未分配的内存内存管理是两个不同的正交事物。

将 wlm_query_slot_count 视为 Excel 中的单元格合并。如果您有 5 个单元格（队列中有 5 个插槽），则默认情况下每个文本只能占用 1 个单元格（1 个插槽）。通过为查询明确设置 wlm_query_slot_count ，您是在告诉 Redshift 合并该位文本（查询）的单元格（插槽）。因此，如果您将 wlm_query_slot_count 设置为 3，则此特定查询将占用 3 个插槽，就像决定将长文本传播到 Excel 中的 3 个合并单元格中一样。

从队列管理的角度来看，这就好像有人已经占用了 3 个插槽。因此，队列中只允许再添加 2 个 1-slot 查询，其他所有人都必须等待。

在内存方面，队列总体上具有固定的内存分配，在插槽之间平均分布。因此，如果整个队列有 100GB 的内存，5 个插槽，每个插槽将获得 20GB。在此队列中分配 3 个插槽的查询将获得 60GB。

并且“未分配的内存管理”与此正交 - 无论插槽和队列如何，如果需要内存并且未分配，Redshift 可以自行决定将其提供给任何查询（我认为“如果队列请求额外内存”具有误导性），通常基于计划/表统计信息。