Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
Come posso utilizzare e gestire l'allocazione di memoria di Amazon Redshift WLM?
Desidero controllare la concorrenza e l'allocazione di Amazon Redshift Workload Management (WLM) alle code.
Breve descrizione
Per configurare WLM in modo da gestire efficacemente le risorse, utilizza uno dei seguenti metodi:
- WLM automatico: Amazon Redshift gestisce il livello di concorrenza delle code e l'allocazione di memoria per ogni query inviata. La query inviata consente di definire la priorità delle query del carico di lavoro o degli utenti rispetto a ciascuna coda di query.
- WLM manuale: Hai un maggiore controllo sul livello di concorrenza e sull'allocazione di memoria alle code. Di conseguenza, le query con un maggiore consumo di risorse possono essere eseguite in code con una maggiore allocazione delle risorse.
È consigliabile utilizzare WLM automatico perché sfrutta il machine learning per prevedere la quantità di memoria da assegnare alle query. Se utilizzi WLM manuale e desideri migrare a WLM automatico, consulta Migrazione da WLM manuale a WLM automatico.
Nota: per definire i limiti delle prestazioni basati su metriche, utilizza una regola di monitoraggio delle query (QMR) con la configurazione WLM.
Risoluzione
Per verificare il livello di concorrenza e l'allocazione di WLM alle code, intraprendi le seguenti azioni:
- Verifica l'attuale configurazione WLM del cluster Amazon Redshift.
- Crea una configurazione WLM di prova e specifica la distribuzione e il livello di concorrenza della coda di query.
- (Facoltativo) Se utilizzi WLM manuale, stabilisci in che modo distribuire la memoria tra gli slot.
Verifica l'attuale configurazione WLM e l'utilizzo della memoria
Utilizza la tabella STV_WLM_SERVICE_CLASS_CONFIG per verificare l'attuale configurazione WLM del cluster Amazon Redshift.
Esempio di configurazione WLM:
[ { "query_concurrency": 2, "memory_percent_to_use": 30, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group1" ], "user_group_wild_card": 0, "rules": [ { "rule_name": "BlockstoDiskSpill", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 50 } ], "action": "abort" } ] }, { "query_concurrency": 5, "memory_percent_to_use": 40, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group2" ], "user_group_wild_card": 0 }, { "query_concurrency": 5, "memory_percent_to_use": 10, "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "rules": [ { "rule_name": "abort_query", "predicate": [ { "metric_name": "scan_row_count", "operator": ">", "value": 1000 } ], "action": "abort" } ] }, { "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "auto_wlm": false }, { "short_query_queue": false } ]
Nota: l'esempio di configurazione WLM precedente è in formato JSON e utilizza la regola QMR, Queue 1. Nell'esempio, memory_percent_to_use è la quantità effettiva di memoria di lavoro assegnata alla classe di servizio.
Amazon Redshift alloca la memoria dal pool di risorse condivise nel cluster. La coda 1 (Queue 1) ha un'allocazione di memoria del 30% divisa in due slot uguali perché la concorrenza è impostata su 2. Ogni slot riceve una quota pari al 15% dell'allocazione di memoria corrente.
La Coda 2 (Queue 2) ha un'allocazione di memoria del 40% divisa in cinque slot uguali perché la concorrenza è impostata su 5. Ogni slot riceve rispettivamente l'8% dell'allocazione di memoria. La coda predefinita utilizza il 10% dell'allocazione di memoria con un livello di concorrenza della coda pari a 5.
Utilizza la seguente query per verificare la configurazione della classe di servizio:
select rtrim(name) as name, num_query_tasks as slots, query_working_mem as mem, max_execution_time as max_time, user_group_wild_card as user_wildcard, query_group_wild_card as query_wildcard from stv_wlm_service_class_config where service_class > 4;
Esempio di output:
name | slots | mem | max_time | user_wildcard | query_wildcard ----------------------------------------------------+-------+-----+----------+---------------+---------------- Service class for super user | 1 | 297 | 0 | false | false Queue 1 | 2 | 522 | 0 | false | false Queue 2 | 5 | 278 | 0 | false | false Default queue | 5 | 69 | 0 | false | false Service class for vacuum/analyze | 0 | 0 | 0 | false | false
La coda 1 (Queue 1) ha un numero di slot pari a 2 e la memoria allocata per ogni slot, o nodo, è di 522 MB. L'allocazione di memoria assegnata alla classe di servizio è la quantità effettiva di memoria di lavoro corrente in MB per slot per ciascun nodo.
Nota: se vengono utilizzati tutti gli slot di query, Amazon Redshift gestisce la memoria non allocata. Quando una coda richiede memoria aggiuntiva, il sistema fornisce temporaneamente memoria non allocata alla coda.
Per ulteriori informazioni sulla gestione della memoria non allocata, consulta Percentuale di memoria WLM da utilizzare.
Identifica i parametri di ottimizzazione di alto livello
Utilizza la tabella SVL_QUERY_METRICS_SUMMARY per controllare l'esecuzione dettagliata e la colonna query_queue_time per visualizzare le query in coda. La colonna query_queue_time mostra che la query è in coda per l'esecuzione di uno slot WLM.
Esempio di tabella:
dev=# select userid, query, service_class, query_cpu_time, query_blocks_read, query_execution_time, query_cpu_usage_percent, query_temp_blocks_to_disk, query_queue_time from SVL_QUERY_METRICS_SUMMARY where query=29608; userid | query | service_class | query_cpu_time | query_blocks_read | query_execution_time | query_cpu_usage_percent | query_temp_blocks_to_disk | query_queue_time --------+-------+---------------+----------------+-------------------+----------------------+-------------------------+---------------------------+------------------ 100 | 29608 | 8 | 18 | 942 | 64 | 10.05 | | (1 row) ev=# select query, step, rows, workmem, label, is_diskbased from svl_query_summary where query = 29608 order by workmem desc; query | step | rows | workmem | label | is_diskbased -------+------+----------+----------+-----------------------------------------+-------------- 29608 | 3 | 49999 | 54263808 | hash tbl=714 | f 29608 | 2 | 49999 | 0 | project | f 29608 | 0 | 49999 | 0 | scan tbl=255079 name=part | f 29608 | 1 | 49999 | 0 | project | f 29608 | 6 | 1561938 | 0 | return | f 29608 | 4 | 1561938 | 0 | project | f 29608 | 5 | 1561938 | 0 | project | f 29608 | 2 | 29995220 | 0 | project | f 29608 | 1 | 1561938 | 0 | return | f 29608 | 1 | 29995220 | 0 | project | f 29608 | 0 | 1561938 | 0 | scan tbl=4893 name=Internal Worktable | f 29608 | 3 | 1561938 | 0 | hjoin tbl=714 | f 29608 | 0 | 29995220 | 0 | scan tbl=255087 name=lineorder | f (13 rows)
Utilizza la tabella SVL_QUERY_SUMMARY per controllare l'allocazione delle risorse durante ogni fase della query.
Controlla le colonne is_diskbased e workmem per visualizzare l'utilizzo delle risorse. Per ulteriori informazioni, consulta Analisi del riepilogo della query.
Aggiorna le proprietà di configurazione dinamica WLM
Utilizza le proprietà di configurazione dinamica WLM in modo che si adatti alle variazioni dei carichi di lavoro. Puoi applicare proprietà dinamiche al database senza riavviare il cluster. Invece, il passaggio da WLM automatico a WLM manuale e viceversa è statico e richiede un riavvio del cluster per avere effetto.
Per ulteriori informazioni, consulta STV_WLM_SERVICE_CLASS_CONFIG.
Di seguito è riportato un esempio di cluster configurato con due code:
Queue Concurrency % Memory to Use 1 5 60% 2 5 40%
Se il cluster dispone di 200 GB di memoria disponibile, l'allocazione di memoria corrente per ciascuno degli slot della coda è simile all'esempio seguente:
Queue 1: (200 GB * 60% ) / 5 slots = 24 GB Queue 2: (200 GB * 40% ) / 5 slots = 16 GB
Per aggiornare le proprietà di configurazione WLM in modo che siano dinamiche, modifica le impostazioni. Consulta il seguente esempio di modifica:
Queue Concurrency % Memory to Use 1 3 75% 2 4 25%
Dopo aver modificato la configurazione WLM, l'allocazione di memoria si aggiorna per adattarsi al carico di lavoro modificato. Consulta il seguente esempio:
Queue 1: (200 GB * 75% ) / 3 slots = 50 GB Queue 2: (200 GB * 25% ) / 4 slots = 12.5 GB
Nota: se sono presenti quey nella coda WLM durante un aggiornamento dinamico della configurazione, Amazon Redshift attende che vengano completate. Una volta completate, Amazon Redshift aggiorna il cluster con le impostazioni aggiornate.
Utilizza la tabella STV_WLM_SERVICE_CLASS_CONFIG quando passi alle proprietà di configurazione WLM dinamiche.
Se i valori num_query_tasks e target_num_query_tasks sono diversi, è in corso una transizione WLM dinamica. Un valore di -1 indica che è configurato WLM automatico.
Identifica la memoria insufficiente allocata alla query
Se il piano di esecuzione di una query in SVL_QUERY_SUMMARY ha un valore is_diskbased corrispondente a true, alloca più memoria alla query. Per allocare più memoria, aumenta il numero di slot di query.
Per ulteriori informazioni, consulta wlm_query_slot_count.
- Argomenti
- Analytics
- Lingua
- Italiano

Contenuto pertinente
AWS UFFICIALEAggiornata 3 anni fa