Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 動態 WLM 範例 透過 Amazon Redshift 即可使用動態 WLM (工作負載管理) 來自動管理 Amazon Redshift 叢集中的工作負載分佈和資源配置。動態 WLM 是工作負載管理 (WLM) 組態的範例，其根據工作負載需求動態調整記憶體配置，藉此實現最佳並行和效能。下節提供實作和設定 Amazon Redshift 叢集的動態 WLM 的詳細資訊。 假設您的叢集 WLM 使用下列動態屬性設定兩個佇列。 | 佇列 | 並行 | 要使用的記憶體 % | | --- | --- | --- | | 1 | 4 | 50% | | 2 | 4 | 50% | 現在，假設您的叢集有 200 GB 的記憶體可供查詢處理使用。(此為任意數字，僅供示範用途。) 如下列方程式所示，每個槽配置 25 GB。 ``` (200 GB * 50% ) / 4 slots = 25 GB ``` 接下來，您將 WLM 變更為使用下列動態屬性。 | 佇列 | 並行 | 要使用的記憶體 % | | --- | --- | --- | | 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，所有可用的記憶體都已配置。 轉移完成，所有查詢槽都可供排入佇列的查詢使用。