Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Proprietà di configurazione dinamiche e statiche WLM Le proprietà della configurazione WLM sono dinamiche o statiche. Puoi applicare proprietà dinamiche al database senza riavviare il cluster, ma le proprietà statiche richiedono un riavvio del cluster affinché le modifiche abbiano effetto. Tuttavia, se si modificano contemporaneamente le proprietà dinamiche e statiche, è necessario riavviare il cluster affinché tutte le modifiche diventino effettive (indipendentemente dal tipo di proprietà). Durante l'applicazione delle proprietà dinamiche, lo stato dei cluster è `modifying`. Il passaggio tra WLM automatico e WLM manuale è una modifica statica che per essere effettiva richiede l'esecuzione di un riavvio del cluster. La tabella seguente indica quali proprietà WLM sono dinamiche o statiche quando si utilizza WLM automatico o WLM manuale. **** | Proprietà WLM | WLM automatico | WLM manuale | | --- | --- | --- | | Gruppi di query | Dinamico | Statico | | Carattere jolly per gruppi di query | Dinamico | Statico | | Gruppi di utenti | Dinamico | Statico | | Carattere jolly per gruppi di utenti | Dinamico | Statico | | Ruoli utente | Dinamico | Statico | | Carattere jolly del ruolo utente | Dinamico | Statico | | Simultaneità nel cluster principale | Non applicabile | Dinamico | | Modalità Dimensionamento simultaneo | Dinamico | Dinamico | | Abilitazione dell'accelerazione di query brevi | Non applicabile | Dinamico | | Tempo di esecuzione massimo per query brevi | Dinamico | Dinamico | | Percentuale di memoria da utilizzare | Non applicabile | Dinamico | | Timeout | Non applicabile | Dinamico | | Priorità | Dinamico | Non applicabile | | Aggiunta o rimozione di code | Dinamico | Statico | Se aggiungi una regola di monitoraggio delle query (QMR) oppure modifichi o elimini una QMR esistente, la modifica viene eseguita automaticamente senza la necessità di riavviare il cluster. **Nota** Quando utilizzi WLM manuale, se il valore di timeout viene modificato, il nuovo valore è applicato a tutte le query la cui esecuzione inizia dopo la modifica del valore. Se la simultaneità o la percentuale di memoria da utilizzare viene modificata, Amazon Redshift passa alla nuova configurazione in modo dinamico. Di conseguenza, le query attualmente in esecuzione non sono coinvolte dalla modifica. Per ulteriori informazioni, consultare [Allocazione della memoria dinamica WLM](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-dynamic-memory-allocation.html). **Topics** + [Allocazione della memoria dinamica WLM](cm-c-wlm-dynamic-memory-allocation.md) + [Esempio di WLM dinamico](cm-c-wlm-dynamic-example.md) # Allocazione della memoria dinamica WLM In ogni coda, WLM crea un numero di slot di query pari al livello di simultaneità della coda. La quantità di memoria allocata a uno slot di query equivale alla percentuale di memoria allocata alla coda divisa per il conteggio degli slot. Se si modifica la simultaneità o l'allocazione della memoria, Amazon Redshift gestisce in modo dinamico la transizione alla nuova configurazione WLM. Pertanto, le query attive possono essere eseguite fino al completamento utilizzando la quantità di memoria correntemente allocata. Allo stesso tempo, Amazon Redshift si accerta che l'utilizzo totale della memoria non superi mai il 100% della memoria disponibile. Il gestore del carico di lavoro utilizza il seguente processo per gestire la transizione: 1. WLM ricalcola l'allocazione della memoria per ogni nuovo slot di query. 1. Se uno slot di query non viene utilizzato attivamente da una query in esecuzione, WLM rimuove lo slot, rendendo disponibile la memoria per i nuovi slot. 1. Se uno slot di query è utilizzato attivamente, WLM attende la fine della query. 1. Quando le query attive vengono completate, gli slot vuoti vengono rimossi e la memoria associata viene liberata. 1. Man mano che la memoria sufficiente diventa disponibile per aggiungere uno o più slot, i nuovi slot vengono aggiunti. 1. Al termine di tutte le query che erano in esecuzione al momento della modifica, il numero degli slot equivale al nuovo livello di simultaneità e la transizione alla nuova configurazione WLM è completa. In effetti, le query in esecuzione quando la modifica ha effetto continuano a utilizzare l'allocazione originale della memoria. Le query che sono in coda quando la modifica ha effetto vengono indirizzate ai nuovi slot non appena diventano disponibili. Se le proprietà dinamiche WLM vengono modificate durante il processo di transizione, WLM inizia immediatamente la transizione alla nuova configurazione, a partire dallo stato corrente. Per visualizzare lo stato della transizione, esegui la query sulla tabella di sistema [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md). # Esempio di WLM dinamico Con Amazon Redshift puoi gestire automaticamente la distribuzione dei carichi di lavoro e l’allocazione delle risorse nei cluster Amazon Redshift utilizzando la gestione dei carichi di lavoro dinamica. WLM dinamica è un esempio di configurazione della gestione dei carichi di lavoro che regola dinamicamente le allocazioni di memoria in base alle richieste dei carichi di lavoro, garantendo una simultaneità e prestazioni ottimali. Nella sezione seguente vengono forniti i dettagli sull’implementazione e sulla configurazione di WLM dinamica per i cluster Amazon Redshift. Supponiamo che il WLM del cluster sia configurato con due code tramite le seguenti proprietà dinamiche. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/cm-c-wlm-dynamic-example.html) Ora supponiamo che il tuo cluster abbia 200 GB di memoria disponibile per l'elaborazione delle query. Questo numero è arbitrario e viene utilizzato solo a scopo illustrativo. Come mostra la seguente equazione, a ogni slot sono allocati 25 GB. ``` (200 GB * 50% ) / 4 slots = 25 GB ``` Successivamente, modifichi WLM per utilizzare le seguenti proprietà dinamiche. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/cm-c-wlm-dynamic-example.html) Come mostra la seguente equazione, la nuova allocazione di memoria per ogni slot nella coda 1 è di 50 GB. ``` (200 GB * 75% ) / 3 slots = 50 GB ``` Supponiamo che le query A1, A2, A3 e A4 siano in esecuzione quando viene applicata la nuova configurazione e le query B1, B2, B3 e B4 siano in coda. WLM riconfigura dinamicamente gli slot delle query come segue. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/cm-c-wlm-dynamic-example.html) 1. WLM ricalcola l'allocazione della memoria per ogni slot di query. Originariamente, alla coda 1 erano allocati 100 GB. La nuova coda ha una allocazione totale di 150 GB e pertanto ha immediatamente 50 GB disponibili. La coda 1 ora utilizza quattro slot e il nuovo livello di simultaneità è tre slot, quindi non vengono aggiunti nuovi slot. 1. Al termine di una query, lo slot viene rimosso e vengono liberati 25 GB. La coda 1 ora ha tre slot e 75 GB di memoria disponibile. La nuova configurazione richiede 50 GB per ogni nuovo slot, ma il nuovo livello di simultaneità è tre slot, quindi non vengono aggiunti nuovi slot. 1. Al termine di una seconda query, lo slot viene rimosso e vengono liberati 25 GB. La coda 1 ora ha due slot e 100 GB di memoria disponibile. 1. Viene aggiunto un nuovo slot utilizzando 50 GB di memoria disponibile. La coda 1 ora ha tre slot e 50 GB di memoria disponibile. Le query in coda possono ora essere indirizzate al nuovo slot. 1. Al termine di una terza query, lo slot viene rimosso e vengono liberati 25 GB. La coda 1 ora ha due slot e 75 GB di memoria disponibile. 1. Viene aggiunto un nuovo slot utilizzando 50 GB di memoria disponibile. La coda 1 ora ha tre slot e 25 GB di memoria disponibile. Le query in coda possono ora essere indirizzate al nuovo slot. 1. Al termine di una quarta query, lo slot viene rimosso e vengono liberati 25 GB. La coda 1 ora ha due slot e 50 GB di memoria disponibile. 1. Viene aggiunto un nuovo slot utilizzando 50 GB di memoria disponibile. La coda 1 ora ha tre slot con 50 GB ciascuno e tutta la memoria disponibile è stata allocata. La transizione è completa e tutti gli slot di query sono disponibili per le query in coda.