定义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。”< / p>
这与内存分配有关吗？可以使用查询槽数调整来暂时消耗比通常允许的整个队列更多的内存吗？
我认为我的问题实际上是关于第一个引用的这一部分，“任何未分配的内存都由Amazon Redshift管理，如果队列请求额外的内存进行处理，可以暂时将其提供给队列。 “
这是否意味着运行查询的用户必须专门请求额外的内存？这是否意味着除非您提出这些特定请求，否则保留一些未分配的内存是没有用的？
答案 0 :(得分：6)
wlm_query_slot_count和队列内存分配这两个概念是不同的。
例如，当您将群集的并发级别分配给20时，您将创建20个执行槽。如果这些较小的插槽（与默认的较大的5个插槽相比）对于某些查询（例如VACUUM或更大的报告）来说太小，则可以使用wlm_query_slot_count为这些特定查询提供多个插槽而不是单个插槽。
在CPU，IO和RAM方面对各个插槽的资源分配不一定是统一的，因为您可以为某些队列提供比其他队列更多的内存，因为发送到此队列的查询需要更多记忆。当您在计算过程中看到更多查询溢出到磁盘时，您可以知道需要更多内存。
对于您正在运行的每个查询，Redshift将根据您正在命中的列以及您在这些列上应用的函数来估计内存要求（这是使列定义尽可能窄的另一个好理由） 。如果WLM具有未分配的内存，则可以将其中的一部分提供给需要它的查询。
然而，当您创建此类队列定义时，您在群集上缺少为查询分配资源的灵活性。例如，您可能会创建一个完全阻塞的队列，而其他队列处于空闲状态并浪费群集资源。因此，请小心操作，并监视这些队列的使用情况，以验证您实际上是在改进群集优先级和性能，而不是伤害它。
答案 1 :(得分：4)
简短的回答是 - 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槽查询进入队列，其他人都必须等待。
就内存而言，队列总体上具有固定的内存分配，在插槽之间平均分配。因此，如果整个队列有100GB的内存，5个插槽，每个插槽将获得20GB。在这个队列中给出3个插槽的查询将获得60GB。
＆＃34;未分配的内存管理＆＃34;与此正交 - 无论插槽和队列如何，如果需要内存且未分配，Redshift可自行决定将其提供给任何查询（我认为＆＃34的措辞;如果队列请求额外的内存＆＃ 34;具有误导性），通常基于计划/表格统计。