从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://www.amazonaws.cn/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

# 动态 WLM 示例
<a name="cm-c-wlm-dynamic-example"></a>

借助 Amazon Redshift，您可以使用动态 WLM（工作负载管理）自动管理 Amazon Redshift 集群的工作负载分配和资源分配。动态 WLM 是工作负载管理（WLM）配置的一个示例，可根据工作负载需求动态调整内存分配，从而实现最佳并发性和性能。下一节将详细介绍如何为 Amazon Redshift 集群实施和配置动态 WLM。

假定您的集群 WLM 使用了以下动态属性配置了两个队列。


| Queue | 并发 | 使用的内存百分比 | 
| --- | --- | --- | 
| 1 | 4 | 50% | 
| 2 | 4 | 50% | 

现在，假定集群有 200 GB 内存可用于查询处理。（此数字是随机的，只是为了演示目的。） 如下面的等式所示，每个槽分配 25 GB 内存。

```
(200 GB * 50% ) / 4 slots  = 25 GB
```

接下来，将 WLM 更改为使用以下动态属性。


| Queue | 并发 | 使用的内存百分比 | 
| --- | --- | --- | 
| 1 | 3 | 75% | 
| 2 | 4 | 25% | 

如下面的等式所示，队列 1 中每个槽的新内存分配为 50 GB。

```
(200 GB * 75% ) / 3 slots = 50 GB 
```

假定在应用新配置时，查询 A1、A2、A3、A4 正在运行，查询 B1、B2、B3、B4 正在排队。WLM 动态重新配置查询槽，如下所示。


| 步骤 | 正在运行的查询 | 当前槽数 | 目标槽数 | 分配的内存 | 可用内存 | 
| --- | --- | --- | --- | --- | --- | 
|  1 |  A1、A2、A3、A4  | 4 | 0 | 100 GB |  50 GB | 
|  2 |  A2、A3、A4  | 3 | 0 |  75 GB |  75 GB | 
|  3 |  A3、A4 | 2 | 0 |  50 GB |  100 GB | 
|  4 |  A3、A4、B1 | 2 | 1 | 100 GB |  50 GB | 
|  5 |  A4、B1 | 1 | 1 |  75 GB |  75 GB | 
|  6 |  A4、B1、B2 | 1 | 2 | 125 GB |  25 GB | 
|  7 |  B1、B2 | 0 | 2 | 100 GB |  50 GB | 
|  8 |  B1、B2、B3 | 0 | 3 | 150 GB |  0 GB | 

1. WLM 重新计算每个查询槽的内存分配。最初，队列 1 分配 100 GB 内存。新的队列总共分配 150 GB 内存，因此，新队列立即有 50 GB 内存可用。队列 1 现在使用四个槽，新的并发级别为三个槽，因此，不添加任何新槽。

1. 当某个查询完成时，该槽被删除并释放 25 GB 内存。队列 1 现有三个槽和 75 GB 可用内存。新配置需要为每个槽分配 50 GB 内存，但新的并发级别为三个槽，因此不添加任何新的槽。

1. 当第二个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 100 GB 可用内存。

1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽和 50 GB 可用内存。排队的查询现在可路由到新的槽。

1. 在第三个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 75 GB 可用内存。

1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽和 25 GB 内存。排队的查询现在可路由到新的槽。

1. 当第四个查询完成时，其槽被删除并释放 25 GB 内存。队列 1 现有两个槽和 50 GB 可用内存。

1. 使用 50 GB 可用内存添加新槽。队列 1 现有三个槽，每个槽有 50 GB 内存，所有可用内存均已分配。

过渡完成，所有查询槽都可用于排队的查询。