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à.
Tutorial: Configurazione delle code di gestione manuale del carico di lavoro () WLM
Con Amazon Redshift, puoi configurare code di gestione manuale del carico di lavoro (WLM) per assegnare priorità e allocare risorse per diversi tipi di query e utenti. Le WLM code manuali consentono di controllare la memoria e le impostazioni di concorrenza per code specifiche, garantendo che i carichi di lavoro critici ricevano le risorse necessarie ed evitando che le query a bassa priorità monopolizzino il sistema. Le seguenti sezioni ti guidano nel processo di creazione e configurazione delle WLM code manuali in Amazon Redshift per soddisfare i tuoi requisiti di gestione del carico di lavoro.
Panoramica
Consigliamo di configurare la gestione automatica del carico di lavoro (WLM) in Amazon Redshift. Per ulteriori informazioni sull'automazioneWLM, consulta. Gestione dei carichi di lavoro Tuttavia, se hai bisogno di più WLM code, questo tutorial illustra il processo di configurazione della gestione manuale del carico di lavoro (WLM) in Amazon Redshift. La configurazione manuale consente di migliorare WLM le prestazioni delle query e l'allocazione delle risorse nel cluster.
Amazon Redshift instrada le query degli utenti alle code per l'elaborazione. WLMdefinisce il modo in cui tali interrogazioni vengono instradate alle code. Per impostazione predefinita, in Amazon Redshift sono disponibili due code per le query: una per gli utenti con privilegi avanzati e una per gli utenti. La coda dell'utente con privilegi avanzati non può essere configurata e può elaborare una sola query per volta. È consigliabile riservare questa coda solo per la risoluzione dei problemi. La coda per gli utenti può elaborare fino a cinque code per volta tuttavia, se necessario, si può modificare il livello di simultaneità della coda.
Se più utenti eseguono query sul database, potrebbe essere più efficace una configurazione diversa. Ad esempio, se alcuni utenti eseguono operazioni che richiedono molte risorse, ad esempio, queste potrebbero avere un impatto negativo sulle query meno impegnativeVACUUM, come i report. Potresti valutare l'opportunità di aggiungere altre code e di configurarle per carichi di lavoro diversi.
Tempo previsto: 75 minuti
Costo previsto: 50 centesimi
Prerequisiti
Sono necessari un cluster Amazon Redshift, il TICKIT database di esempio e lo strumento client Amazon RSQL Redshift. Se non li hai già configurati, consulta la Amazon Redshift Getting Started Guide e Amazon Redshift. RSQL
Sections
Sezione 1: informazioni sul comportamento predefinito di elaborazione delle code
Prima di iniziare a configurare manualmenteWLM, è utile comprendere il comportamento predefinito dell'elaborazione delle code in Amazon Redshift. In questa sezione creerai due viste database che restituiscono informazioni da diverse tabelle di sistema. Quindi eseguirai alcune query di prova per vedere come vengono instradate per impostazione predefinita. Per ulteriori informazioni sulle tabelle di sistema, consultare Riferimento di tabelle e viste di sistema.
Fase 1: creare la vista WLM _ QUEUE _ STATE _VW
In questo passaggio, si crea una vista denominata WLM _ QUEUE _ STATE _VW. Questa vista restituisce informazioni dalle tabelle di sistema seguenti.
Utilizzerai questa visualizzazione durante tutto il tutorial per monitorare cosa succede alle code dopo aver modificato la configurazione. WLM La tabella seguente descrive i dati restituiti dalla vista WLM _ QUEUE _ STATE _VW.
| Colonna | Descrizione |
|---|---|
| coda | Il numero associato alla riga che rappresenta una coda. Il numero di coda determina l'ordine delle code nel database. |
| description | Valore che descrive se la coda è disponibile solo per determinati gruppi di utenti, determinati gruppi di query o per tutti i tipi di query. |
| slots | Il numero di slot assegnate alla coda. |
| mem | La quantità di memoria, espressa in MB per slot, allocata alla coda. |
| max_execution_time | La quantità massima di tempo consentita per l'esecuzione di una query prima che venga terminata. |
| user_* | Un valore che indica se i caratteri jolly sono consentiti nella WLM configurazione per corrispondere ai gruppi di utenti. |
| query_* | Un valore che indica se i caratteri jolly sono consentiti nella WLM configurazione per corrispondere ai gruppi di query. |
| queued | Il numero di query che si trovano nella coda in attesa di essere elaborate. |
| executing | Il numero di query attualmente in esecuzione. |
| executed | Il numero di query che sono state eseguite. |
Per creare la vista WLM _ QUEUE _ STATE _VW
-
Apri Amazon Redshift RSQL e connettiti al tuo database di TICKIT esempio. Se questo database non è presente, vedi Prerequisiti.
-
Esegui la seguente query per creare la vista WLM _ QUEUE _ STATE _VW.
create view WLM_QUEUE_STATE_VW as select (config.service_class-5) as queue , trim (class.condition) as description , config.num_query_tasks as slots , config.query_working_mem as mem , config.max_execution_time as max_time , config.user_group_wild_card as "user_*" , config.query_group_wild_card as "query_*" , state.num_queued_queries queued , state.num_executing_queries executing , state.num_executed_queries executed from STV_WLM_CLASSIFICATION_CONFIG class, STV_WLM_SERVICE_CLASS_CONFIG config, STV_WLM_SERVICE_CLASS_STATE state where class.action_service_class = config.service_class and class.action_service_class = state.service_class and config.service_class > 4 order by config.service_class; -
Eseguire la query seguente per vedere le informazioni incluse nella vista.
select * from wlm_queue_state_vw;Di seguito è riportato un risultato di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 1 | 160
Fase 2: Creare la vista WLM _ QUERY _ STATE _VW
In questo passaggio, si crea una vista denominata WLM _ QUERY _ STATE _VW. Questa vista restituisce informazioni dalla tabella di sistema STV_WLM_QUERY_STATE.
Utilizzerai questa vista in tutto il tutorial per monitorare le query in esecuzione. La tabella seguente descrive i dati restituiti dalla vista WLM _ QUERY _ STATE _VW.
| Colonna | Descrizione |
|---|---|
| query | L'ID di query. |
| coda | Il numero della coda. |
| slot_count | Il numero di slot assegnate alla query. |
| start_time | L'ora in cui è stata avviata la query. |
| stato | Lo stato della query, ad esempio in esecuzione. |
| queue_time | Numero totale di microsecondi che la query ha trascorso nella coda. |
| exec_time | Numero di microsecondi durante i quali la query è stata in esecuzione. |
Per creare la vista WLM _ QUERY _ STATE _VW
-
InRSQL, esegui la seguente query per creare la vista WLM _ QUERY _ STATE _VW.
create view WLM_QUERY_STATE_VW as select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time from stv_wlm_query_state; -
Eseguire la query seguente per vedere le informazioni incluse nella vista.
select * from wlm_query_state_vw;Di seguito è riportato un risultato di esempio.
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1249 | 1 | 1 | 2014-09-24 22:19:16 | Executing | 0 | 516
Fase 3: esecuzione delle query di test
In questo passaggio, si eseguono interrogazioni da più connessioni RSQL e si esaminano le tabelle di sistema per determinare come le query sono state instradate per l'elaborazione.
Per questo passaggio, è necessario aprire due finestre: RSQL
-
Nella RSQL finestra 1, esegui query che monitorano lo stato delle code e le interrogazioni utilizzando le viste già create in questo tutorial.
-
Nella RSQL finestra 2, esegui query di lunga durata per modificare i risultati che trovi nella finestra 1. RSQL
Per eseguire le query di test
-
Aprire due finestreRSQL. Se è già aperta una finestra, sarà sufficiente aprire la seconda. È possibile utilizzare lo stesso account utente per entrambe le connessioni.
-
Nella RSQL finestra 1, esegui la seguente query.
select * from wlm_query_state_vw;Di seguito è riportato un risultato di esempio.
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1258 | 1 | 1 | 2014-09-24 22:21:03 | Executing | 0 | 549Questa query restituisce un risultato autoreferenziale. La query attualmente in esecuzione è l'SELECTistruzione di questa vista. Una query su questa vista restituisce sempre almeno un risultato, che si deve confrontare con quello che si ottiene avviando la query di lunga durata al passaggio successivo.
-
Nella RSQL finestra 2, esegui una query dal database TICKIT di esempio. Questa query dovrebbe durare circa un minuto in modo da avere il tempo di esplorare i risultati della vista WLM _ QUEUE _ STATE _VW e della vista WLM _ QUERY _ STATE _VW che avete creato in precedenza. In alcuni casi, potresti osservare che la query non viene eseguita abbastanza a lungo per interrogare entrambe le viste. In questi casi, puoi aumentare il valore del filtro su
l.listidaffinché la query venga eseguita più a lungo.Nota
Per ridurre il tempo di esecuzione delle query e migliorare le prestazioni del sistema, Amazon Redshift memorizza i risultati di certi tipi di query nella memoria cache del nodo principale. Se è abilitato il caching dei risultati, l'esecuzione delle query successive è moto più rapida. Per evitare che la query venga eseguita troppo rapidamente, è possibile disabilitare il caching dei risultati per la sessione corrente.
Per disattivare il caching dei risultati per la sessione corrente, è possibile impostare il parametro enable_result_cache_for_session su
offcome mostrato di seguito.set enable_result_cache_for_session to off;Nella RSQL finestra 2, esegui la seguente query.
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000; -
Nella RSQL finestra 1, interroga WLM _ QUEUE _ STATE _VW e WLM _ QUERY _ STATE _VW e confronta i risultati con i risultati precedenti.
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 2 | 163 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1267 | 1 | 1 | 2014-09-24 22:22:30 | Executing | 0 | 684 1265 | 1 | 1 | 2014-09-24 22:22:36 | Executing | 0 | 4080859
Di seguito vengono illustrate le differenze tra le query precedenti e i risultati di questa fase:
-
Ora ci sono due righe in WLM _ _ _VW. QUERY STATE Un risultato è l'interrogazione autoreferenziale per eseguire un'SELECToperazione su questa vista. Il secondo risultato è la query di lunga durata della fase precedente.
-
La colonna di esecuzione in WLM _ QUEUE _ STATE _VW è aumentata da 1 a 2. La voce di questa colonna indica che nella coda sono in esecuzione due query.
-
Il valore della colonna eseguita aumenta ogni volta che si esegue una query nella coda.
La vista WLM _ QUEUE _ STATE _VW è utile per avere una visione generale delle code e di quante interrogazioni vengono elaborate in ciascuna coda. La vista WLM _ QUERY _ STATE _VW è utile per ottenere una visione più dettagliata delle singole query attualmente in esecuzione.
Sezione 2: Modifica della configurazione della coda di interrogazioni WLM
Ora che hai capito come funzionano le code di default, puoi imparare a configurare le code di query usando il manuale. WLM In questa sezione creerai e configurerai un nuovo gruppo di parametri per il tuo cluster. Creerai due code utente aggiuntive e le configurerai in modo che accettino le query in base alle etichette del gruppo di utenti o del gruppo di query. Le query che non vengono instradate a una di queste due code verranno instradate alla coda predefinita in fase di runtime.
Per creare una WLM configurazione manuale in un gruppo di parametri
-
Accedi a AWS Management Console e apri la console Amazon Redshift all'indirizzo. https://console.aws.amazon.com/redshiftv2/
-
Dal menu di navigazione scegliere Configurations (Configurazioni), quindi scegliere Workload management (Gestione carichi di lavoro) per visualizzare la pagina Workload management Gestione carichi di lavoro).
-
Scegli Create (Crea) per visualizzare la finestra Create parameter group (Crea gruppo di parametri).
-
Inserire
WLMTutorialper Parameter group name (Nome gruppo di parametri) e Description (Descrizione), quindi scegliere Create (Crea) per creare il gruppo di parametri.Nota
Il Parameter group name (Nome del gruppo di parametri) è trasformato in minuscolo al momento della creazione.
-
Nella pagina Workload management (Gestione workload), scegli il gruppo di parametri
wlmtutorialper visualizzare la pagina dei dettagli con le schede Parameters (Parametri) e Workload management (Gestione workload). -
Conferma di essere nella scheda Gestione del carico di lavoro, quindi scegli la WLMmodalità Switch per visualizzare la finestra delle impostazioni Concurrency.
-
Scegli Manuale WLM, quindi scegli Salva per passare alla modalità manuale. WLM
-
Scegli Edit workload queues (Modifica code di workload).
-
Scegli Add queue (Aggiungi coda) due volte per aggiungere due code. Ora sono presenti tre code: Queue 1 (Coda 1), Queue 2 (Coda 2) e Default queue (Coda predefinita).
-
Inserisci le informazioni per ogni coda come segue:
-
Per Coda 1, inserire
30alla voce Memoria (%),2alla voce Simultaneità su principale etestalla voce Gruppi di query. Lascia le altre impostazioni con i valori predefiniti. -
Per Coda 2, inserire
40alla voce Memoria (%),3alla voce Simultaneità su principaleeadminalla voce Gruppi di utenti. Lascia le altre impostazioni con i valori predefiniti. -
Non apportare alcuna modifica alla Default queue (Coda predefinita). WLMassegna la memoria non allocata alla coda predefinita.
-
-
Per salvare le impostazioni, scegli Save (Salva).
Successivamente, associa il gruppo di parametri con la WLM configurazione manuale a un cluster.
Per associare un gruppo di parametri a una WLM configurazione manuale con un cluster
-
Accedi a AWS Management Console e apri la console Amazon Redshift all'indirizzo. https://console.aws.amazon.com/redshiftv2/
-
Dal menu di navigazione, scegliere Clusters (Cluster), quindi scegliere Clusters (Cluster) per visualizzare un elenco dei cluster.
-
Selezionare il cluster, come
exampleclusterper visualizzarne i dettagli. Quindi scegliere la scheda Proprietà per visualizzare le proprietà del cluster. -
Nella sezione Configurazioni del database, scegliere Modifica, Modifica il gruppo di parametri per visualizzare la finestra dei gruppi di parametri.
-
Per Gruppi di parametri scegliere il gruppo di parametri
wlmtutorialcreato in precedenza. -
Scegliere Salva le modifiche per associare il gruppo di parametri.
Il cluster viene aggiornato con il gruppo di parametri modificato. Tuttavia, è necessario riavviare il cluster affinché le modifiche vengano applicate anche al database.
-
Scegliere il cluster, quindi selezionare Riavvia alla voce Operazioni.
Dopo il riavvio del cluster, il suo stato torna a essere Available (Disponibile).
Sezione 3: instradamento delle query alle code in base ai gruppi di utenti e ai gruppi di query
Ora il cluster è associato a un nuovo gruppo di parametri e l'hai configuratoWLM. Successivamente, eseguire alcune query per vedere come Amazon Redshift le instrada sulle code per l'elaborazione.
Fase 1: visualizzazione della configurazione delle code di query nel database
Innanzitutto, verifica che il database abbia la WLM configurazione che ti aspetti.
Per visualizzare la configurazione delle code di query
-
Apri RSQL ed esegui la seguente query. L'interrogazione utilizza la vista WLM _ QUEUE _ STATE _VW in cui è stata creata. Fase 1: creare la vista WLM _ QUEUE _ STATE _VW Se prima del riavvio del cluster al database è già connessa una sessione, sarà necessario riconnetterla.
select * from wlm_queue_state_vw;Di seguito è riportato un risultato di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0Confronta questi risultati on quelli ricevuti in Fase 1: creare la vista WLM _ QUEUE _ STATE _VW. Come puoi notare, ora sono presenti due code aggiuntive. La coda 1 ora è la coda per il gruppo di query di verifica, mentre la coda 2 è quella per il gruppo di utenti amministratori.
La coda 3 è quella predefinita. L'ultima coda nell'elenco è sempre la coda predefinita. Si tratta della coda a cui vengono instradate le query se non è specificato un gruppo di utenti o di query.
-
Esegui la query seguente per verificare che venga eseguita nella coda 3.
select * from wlm_query_state_vw;Di seguito è riportato un risultato di esempio.
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2144 | 3 | 1 | 2014-09-24 23:49:59 | Executing | 0 | 550430
Fase 2: esecuzione di una query tramite la coda del gruppo di query
Per eseguire una query tramite la coda del gruppo di query
-
Eseguire la seguente query per instradarla al gruppo di query
test.set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Dall'altra RSQL finestra, esegui la seguente query.
select * from wlm_query_state_vw;Di seguito è riportato un risultato di esempio.
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2168 | 1 | 1 | 2014-09-24 23:54:18 | Executing | 0 | 6343309 2170 | 3 | 1 | 2014-09-24 23:54:24 | Executing | 0 | 847La query è stata instradata al gruppo di query di verifica, che ora è la coda 1.
-
Seleziona tutto nella vista dello stato della coda.
select * from wlm_queue_state_vw;Sarà visualizzato un risultato simile al seguente.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0 -
Reimposta il gruppo di query ed esegui nuovamente la query lunga:
reset query_group; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Eseguire le query sulle viste per vedere i risultati.
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 2 | 5 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2186 | 3 | 1 | 2014-09-24 23:57:52 | Executing | 0 | 649 2184 | 3 | 1 | 2014-09-24 23:57:48 | Executing | 0 | 4137349Il risultato dovrebbe indicare che la query è ora nuovamente in esecuzione nella coda 3.
Fase 3: creazione di un utente e un gruppo di database
Prima di poter eseguire una query in questa coda, dovrai creare il gruppo di utenti nel database e aggiungere un utente al gruppo. Quindi accedi RSQL utilizzando le credenziali del nuovo utente ed esegui le query. Per creare utenti di database, è necessario eseguire le query come utente con privilegi avanzati, ad esempio l'amministratore.
Per creare un nuovo gruppo di utenti e un nuovo utente di database
-
Nel database, crea un nuovo utente del database denominato
adminwlmeseguendo il seguente comando in una RSQL finestra.create user adminwlm createuser password '123Admin'; -
Quindi eseguire i comandi seguenti per creare il nuovo gruppo di utenti e aggiungervi il nuovo utente
adminwlm.create group admin; alter group admin add user adminwlm;
Fase 4: esecuzione di una query tramite la coda del gruppo di utenti
Successivamente eseguirai una query e la instraderai alla coda del gruppo di utenti. Questa operazione viene eseguita quando si intende instradare la query a una coda configurata per gestire il tipo di query che si desidera eseguire.
Per eseguire una query tramite la coda del gruppo di utenti
-
Nella RSQL finestra 2, esegui le seguenti query per passare all'
adminwlmaccount ed esegui una query come utente.set session authorization 'adminwlm'; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Nella RSQL finestra 1, esegui la seguente query per visualizzare la coda di query a cui vengono indirizzate le query.
select * from wlm_query_state_vw; select * from wlm_queue_state_vw;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 8 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2202 | 2 | 1 | 2014-09-25 00:01:38 | Executing | 0 | 4885796 2204 | 3 | 1 | 2014-09-25 00:01:43 | Executing | 0 | 650La coda in viene eseguita questa query è la 2, ovvero la coda dell'utente
admin. Le query che esegui avendo effettuato l'accesso come questo utente verranno seguite nella coda 2, a meno che non specifichi un gruppo di code diverso da utilizzare. La coda scelta dipende dalle regole di assegnazione delle code. Per ulteriori informazioni, consulta WLMregole di assegnazione delle code. -
Ora esegui la seguente query dalla RSQL finestra 2.
set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Nella RSQL finestra 1, esegui la seguente query per vedere la coda di query a cui vengono indirizzate le query.
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 1 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 10 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2218 | 1 | 1 | 2014-09-25 00:04:30 | Executing | 0 | 4819666 2220 | 3 | 1 | 2014-09-25 00:04:35 | Executing | 0 | 685 -
Al termine, reimposta il gruppo di query.
reset query_group;
Sezione 4: utilizzo di wlm_query_slot_count per ignorare temporaneamente il livello di simultaneità in una coda
Può accadere che gli utenti abbiano l'esigenza temporanea di un numero maggiore di risorse per una query specifica. In questo caso possono utilizzare l'impostazione di configurazione wlm_query_slot_count per ignorare temporaneamente il modo in cui gli slot vengono allocati in una coda di query. Gli slot sono unità di memoria utilizzate per CPU elaborare le interrogazioni. È possibile sovrascrivere il numero di slot quando si eseguono query occasionali che occupano molte risorse nel cluster, ad esempio quando si esegue un'VACUUMoperazione nel database.
Potresti trovare che gli utenti spesso devono impostare wlm_query_slot_count per determinati tipi di query. In tal caso, valuta la possibilità di modificare la WLM configurazione e offrire agli utenti una coda più adatta alle esigenze delle loro query. Per ulteriori informazioni su come ignorare temporaneamente il livello di simultaneità utilizzando il numero di slot, consultare wlm_query_slot_count.
Fase 1: come ignorare il livello di simultaneità utilizzando wlm_query_slot_count
Ai fini di questo tutorial, eseguiamo la stessa query di lunga durata. SELECT La query verrà eseguita come utente adminwlm utilizzando wlm_query_slot_count per aumentare il numero di slot disponibili per la query.
Per ignorare il livello di simultaneità utilizzando wlm_query_slot_count
-
Aumentate il limite della query per assicurarvi di avere abbastanza tempo per interrogare la vista WLM _ QUERY _ STATE _VW e vedere un risultato.
set wlm_query_slot_count to 3; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Ora, interroga WLM _ QUERY _ STATE _VW con l'utente amministratore per vedere come viene eseguita la query.
select * from wlm_query_state_vw;Di seguito è riportato un risultato di esempio.
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2240 | 2 | 1 | 2014-09-25 00:08:45 | Executing | 0 | 3731414 2242 | 3 | 1 | 2014-09-25 00:08:49 | Executing | 0 | 596Il numero di slot per la query è 3. Ciò significa che la query utilizza tutti e tre gli slot per l'elaborazione, allocando tutte le risorse nella coda alla query.
-
Ora esegui la seguente query.
select * from WLM_QUEUE_STATE_VW;Di seguito è riportato un risultato di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 4 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 25L'impostazione di configurazione di wlm_query_slot_count ha validità solo per la sessione corrente. Se la sessione scade o un altro utente esegue una query, viene utilizzata la WLM configurazione.
-
Reimpostare il numero di slot ed eseguire nuovamente il test.
reset wlm_query_slot_count; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 2 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 14 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2260 | 2 | 1 | 2014-09-25 00:12:11 | Executing | 0 | 4042618 2262 | 3 | 1 | 2014-09-25 00:12:15 | Executing | 0 | 680
Fase 2: esecuzione delle query da sessioni diverse
A questo punto eseguire le query da sessioni diverse.
Per eseguire le query da sessioni diverse
-
Nelle RSQL finestre 1 e 2, esegui quanto segue per utilizzare il gruppo di query di test.
set query_group to test; -
Nella RSQL finestra 1, esegui la seguente query a lunga durata.
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Poiché la query a esecuzione prolungata è ancora attiva nella RSQL finestra 1, esegui quanto segue. Questi comandi aumentano il numero di slot per utilizzare tutti gli slot per la coda, quindi avviano l'esecuzione della query di lunga durata.
set wlm_query_slot_count to 2; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
Apri una terza RSQL finestra e interroga le viste per vedere i risultati.
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;Di seguito sono riportati i risultati di esempio.
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 1 | 1 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 18 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+---------------+------------+----------- 2286 | 1 | 2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950 | 0 2282 | 1 | 1 | 2014-09-25 00:16:33 | Executing | 0 | 19335850 2288 | 3 | 1 | 2014-09-25 00:16:52 | Executing | 0 | 666Nota che la prima query utilizza uno degli slot assegnati alla coda 1 per eseguire la query. Inoltre, tieni presente che una query è in attesa nella coda (dove
queuedè1estateèQueuedWaiting). Una volta completata la prima query, inizierà l'esecuzione della seconda. Ciò accade perché entrambe le query sono instradate al gruppo di queryteste la seconda deve attendere che siano disponibili slot sufficienti per iniziare l'elaborazione.
Sezione 5: pulizia delle risorse
Il tuo cluster genera dei costi fino a che è in esecuzione. Una volta completato questo tutorial, ripristinare lo stato precedente dell'ambiente seguendo la procedura descritta in Scoprire risorse aggiuntive e reimpostare l'ambiente nella Guida alle operazioni di base di Amazon Redshift.
Per ulteriori informazioni suWLM, vedereGestione dei carichi di lavoro.
