Come posso risolvere i problemi relativi alle prestazioni dei cluster o delle query in Amazon Redshift?

Descrizione breve

Se riscontri problemi di prestazioni nel tuo cluster Amazon Redshift, prendi in considerazione i seguenti approcci:

• Monitora le metriche delle prestazioni del cluster.
• Consulta i consigli di Amazon Redshift Advisor.
• Esamina gli avvisi di esecuzione delle query e l'uso eccessivo del disco.
• Verifica la presenza di sessioni o transazioni con esecuzioni di lunga durata e problemi di blocco.
• Controlla la configurazione della gestione del carico di lavoro (WLM).
• Verifica la manutenzione e le prestazioni dell'hardware del nodo di cluster.

Soluzione

Monitoraggio delle metriche di prestazioni del cluster

Se riscontri problemi di prestazioni con il tuo cluster Amazon Redshift, consulta le metriche e i grafici delle prestazioni del cluster. Le metriche e i grafici delle prestazioni del cluster possono aiutarti a individuare la possibile causa principale di degrado delle prestazioni. Puoi visualizzare i dati relativi alle prestazioni nella console Amazon Redshift per confrontare le prestazioni del cluster nel tempo.

Un aumento del volume di queste metriche può indicare un aumento del carico di lavoro e del conflitto di risorse sul tuo cluster Amazon Redshift. Per ulteriori informazioni sul monitoraggio delle metriche delle prestazioni, consulta Monitoraggio di Amazon Redshift con i parametri di CloudWatch.

Controlla la suddivisione dell'esecuzione del carico di lavoro nella console Amazon Redshift per esaminare le query e i tempi di esecuzione specifici. Ad esempio, se noti un aumento dei tempi di pianificazione delle query, ciò potrebbe indicare che una query è in attesa di un blocco.

Lettura dei consigli di Amazon Redshift Advisor

Amazon Redshift Advisor offre suggerimenti su come migliorare e ottimizzare le prestazioni del cluster Amazon Redshift. Amazon Redshift Advisor è disponibile gratuitamente nella console Amazon Redshift. Utilizza i consigli di Amazon Redshift Advisor per conoscere le aree di miglioramento potenziali per il tuo cluster. I consigli si basano su modelli di utilizzo comuni e sulle best practice di Amazon Redshift.

Analisi degli avvisi di esecuzione delle query e dell'uso eccessivo del disco

Durante l'esecuzione delle query, Amazon Redshift rileva le prestazioni della query e indica se viene eseguita in modo efficiente. Se la query viene identificata come inefficiente, Amazon Redshift annota l'ID della query e fornisce consigli per il miglioramento delle prestazioni correlate. I consigli vengono registrati in STL_ALERT_EVENT_LOG, una tabella di sistema.

Se osservi una query lenta o inefficiente, controlla le voci STL_ALERT_EVENT_LOG. Per recuperare informazioni dalla tabella STL_ALERT_EVENT_LOG, utilizza la seguente query:

SELECT TRIM(s.perm_table_name) AS TABLE
    , (SUM(ABS(DATEDIFF(SECONDS, Coalesce(b.starttime, d.starttime, s.starttime), CASE
            WHEN COALESCE(b.endtime, d.endtime, s.endtime) > COALESCE(b.starttime, d.starttime, s.starttime)
            THEN COALESCE(b.endtime, d.endtime, s.endtime)
        ELSE COALESCE(b.starttime, d.starttime, s.starttime)
    END))) / 60)::NUMERIC(24, 0) AS minutes
    , SUM(COALESCE(b.ROWS, d.ROWS, s.ROWS)) AS ROWS
    , TRIM(SPLIT_PART(l.event, ':', 1)) AS event
    , SUBSTRING(TRIM(l.solution), 1, 60) AS solution
    , MAX(l.QUERY) AS sample_query
    , COUNT(DISTINCT l.QUERY)
FROM STL_ALERT_EVENT_LOG AS l
LEFT JOIN stl_scan AS s
    ON s.QUERY = l.QUERY AND s.slice = l.slice AND s.segment = l.segment
LEFT JOIN stl_dist AS d
    ON d.QUERY = l.QUERY AND d.slice = l.slice AND d.segment = l.segment
LEFT JOIN stl_bcast AS b
    ON b.QUERY = l.QUERY AND b.slice = l.slice AND b.segment = l.segment
WHERE l.userid > 1 AND l.event_time >= DATEADD(DAY, -7, CURRENT_DATE)
GROUP BY 1, 4, 5
ORDER BY 2 DESC, 6 DESC;

Questa query elenca gli ID delle query, nonché i problemi e le ricorrenze più comuni per la query in esecuzione sul cluster.

Di seguito puoi trovare un esempio di output della query e le informazioni che descrivono il motivo per cui l'avviso è stato attivato:

table | minutes | rows |               event                |                        solution                        | sample_query | count
-------+---------+------+------------------------------------+--------------------------------------------------------+--------------+-------
NULL  |    NULL | NULL | Nested Loop Join in the query plan | Review the join predicates to avoid Cartesian products |      1080906 |     2

Verifica le prestazioni delle query controllando le query diagnostiche per l'ottimizzazione delle query. Assicurati che le operazioni di query siano progettate per essere eseguite in modo efficiente. Ad esempio, non tutte le operazioni join sono efficaci. Un loop join annidato è il tipo di join meno efficace e, se possibile, deve essere evitato perché questo tipo aumenta significativamente il tempo di esecuzione delle query.

Identifica le query che eseguono i nested loop per facilitare la diagnosi del problema. Per ulteriori informazioni su come diagnosticare problemi comuni di uso del disco, vedere Come posso risolvere i problemi relativi all'utilizzo elevato o completo del disco con Amazon Redshift?

Verifica la presenza di problemi di blocco e di sessioni o transazioni di lunga durata

Prima di eseguire una query sul cluster, potrebbe essere necessario ottenere blocchi a livello di tabella sulle tabelle coinvolte nell'esecuzione delle query. Ci possono essere istanze in cui le query possono apparire come "interrotte" oppure in cui si verifica un picco nei tempi di esecuzione delle query. Se osservi un picco nel tempo di esecuzione della query, la causa potrebbe essere un problema di blocco. Per ulteriori informazioni sui tempi di esecuzione ritardati delle query, consulta Perché il mio tempo di pianificazione delle query è così elevato in Amazon Redshift?

Se la tabella risulta bloccata da un altro processo in atto o un'altra query, la query non può procedere. Di conseguenza, non vedrai la tua query apparire nella tabella STV_INFLIGHT. La query in esecuzione verrà invece visualizzata nella tabella STV_RECENTS.

A volte, una query interrotta è causata da una transazione di lunga durata. Per evitare che transazioni a lungo termine influiscano sulle prestazioni delle query, prendi in considerazione i seguenti suggerimenti:

• Identifica le sessioni di lunga durata e interrompile immediatamente. Per verificare le transazioni a lungo termine, puoi utilizzare le tabelle STL_SESSIONS e SVV_TRANSACTIONS.
• Progetta le tue query in modo che Amazon Redshift possa elaborarle in modo rapido ed efficace.

Nota: Le transazioni a lungo termine influiscono anche sulla capacità di VACUUM di recuperare spazio su disco, con conseguente aumento del numero di righe fantasma o righe non salvate. Le righe fantasma analizzate dalle query possono influire sulle prestazioni delle query.

Per ulteriori informazioni sull'identificazione delle sessioni di lunga durata che possono causare il blocco delle tabelle, consulta Come posso rilevare e sbloccare i blocchi in Amazon Redshift?

Verifica della configurazione relativa alla gestione del carico di lavoro

A seconda della configurazione della gestione del carico di lavoro (WLM), una query potrebbe iniziare immediatamente a essere eseguita o rimanere in coda. L'obiettivo dovrebbe sempre essere quello di ridurre al minimo la quantità di tempo in cui una query viene messa in coda per l'esecuzione. Se stai cercando di definire le tue code, controlla l’allocazione della memoria WLM.

Per controllare le code WLM di un cluster nell'arco di alcuni giorni, utilizza la seguente query:

SELECT *, pct_compile_time + pct_wlm_queue_time + pct_exec_only_time + pct_commit_queue_time + pct_commit_time AS total_pcnt
FROM
(SELECT IQ.*,
   ((IQ.total_compile_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_compile_time,
   ((IQ.wlm_queue_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_wlm_queue_time,
   ((IQ.exec_only_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_exec_only_time,
   ((IQ.commit_queue_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) pct_commit_queue_time,
   ((IQ.commit_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) pct_commit_time
  FROM
    (SELECT trunc(d.service_class_start_time) AS DAY,
       d.service_class,
       d.node,
       COUNT(DISTINCT d.xid) AS count_all_xid,
       COUNT(DISTINCT d.xid) -COUNT(DISTINCT c.xid) AS count_readonly_xid,
       COUNT(DISTINCT c.xid) AS count_commit_xid,
       SUM(compile_us) AS total_compile_time,
       SUM(datediff (us,CASE WHEN d.service_class_start_time > compile_start THEN compile_start ELSE d.service_class_start_time END,d.queue_end_time)) AS wlm_queue_time,
       SUM(datediff (us,d.queue_end_time,d.service_class_end_time) - compile_us) AS exec_only_time,
       nvl(SUM(datediff (us,CASE WHEN node > -1 THEN c.startwork ELSE c.startqueue END,c.startwork)),0) commit_queue_time,
       nvl(SUM(datediff (us,c.startwork,c.endtime)),0) commit_time,
       SUM(datediff (us,CASE WHEN d.service_class_start_time > compile_start THEN compile_start ELSE d.service_class_start_time END,d.service_class_end_time) + CASE WHEN c.endtime IS NULL THEN 0 ELSE (datediff (us,CASE WHEN node > -1 THEN c.startwork ELSE c.startqueue END,c.endtime)) END) AS wlm_start_commit_time
     FROM
       (SELECT node, b.*
          FROM (SELECT -1 AS node UNION SELECT node FROM stv_slices) a,
               stl_wlm_query b
         WHERE queue_end_time > '2005-01-01'
           AND exec_start_time > '2005-01-01') d
     LEFT JOIN stl_commit_stats c USING (xid,node)
     JOIN (SELECT query, MIN(starttime) AS compile_start, SUM(datediff (us,starttime,endtime)) AS compile_us
           FROM svl_compile
           GROUP BY 1) e USING (query)
    WHERE d.xid > 0
      AND d.service_class > 4
      AND d.final_state <> 'Evicted'
 GROUP BY trunc(d.service_class_start_time),
          d.service_class,
          d.node
 ORDER BY trunc(d.service_class_start_time),
          d.service_class,
          d.node) IQ)
WHERE node < 0 ORDER BY 1,2,3;

Questa query fornisce il numero totale di transazioni (xid), il tempo di esecuzione, il tempo in coda e i dettagli della coda di commit. Puoi controllare i dettagli della coda di commit per vedere se i commit frequenti influiscono sulle prestazioni del carico di lavoro.

Per verificare i dettagli delle query in esecuzione in un determinato momento, utilizza la seguente query:

select b.userid,b.query,b.service_class,b.slot_count,b.xid,d.pid,d.aborted,a.compile_start,b.service_class_start_time,b.queue_end_time,b.service_class_end_time,c.startqueue as commit_startqueue,c.startwork as commit_startwork,c.endtime as commit_endtime,a.total_compile_time_s,datediff(s,b.service_class_start_time,b.queue_end_time)
    as wlm_queue_time_s,datediff(s,b.queue_end_time,b.service_class_end_time) as wlm_exec_time_s,datediff(s, c.startqueue, c.startwork) commit_queue_s,datediff(s, c.startwork, c.endtime) commit_time_s,undo_time_s,numtables_undone,datediff(s,a.compile_start,nvl(c.endtime,b.service_class_end_time))
    total_query_s ,substring(d.querytxt,1,50) as querytext from (select query,min(starttime) as compile_start,max(endtime) as compile_end,sum(datediff(s,starttime,endtime)) as total_compile_time_s from svl_compile group by query) a left join stl_wlm_query
    b using (query) left join (select * from stl_commit_stats where node=-1) c using (xid) left join stl_query d using(query) left join (select xact_id_undone as xid,datediff(s,min(undo_start_ts),max(undo_end_ts)) as undo_time_s,count(distinct table_id)
    numtables_undone from stl_undone group by 1) e on b.xid=e.xid
WHERE '2011-12-20 13:45:00' between compile_start and service_class_end_time;

Sostituisci "2011-12-20 13:45:00" con l'ora e la data specifiche che desideri controllare per le query in coda e quelle completate.

Esame delle prestazioni hardware del tuo nodo di cluster

Durante la finestra di manutenzione del cluster, possono essere eseguite attività di manutenzione come, ad esempio, l'applicazione di patch, le modifiche alla configurazione interna e la sostituzione di nodi. Se un nodo è stato sostituito durante la finestra di manutenzione, il cluster potrebbe essere disponibile in breve tempo. Tuttavia, il ripristino dei dati sul nodo sostituito potrebbe richiedere un po' di tempo. Questo processo è noto come "idratazione". Durante il processo di idratazione, le prestazioni del cluster potrebbero diminuire.

Per identificare quali eventi (come, ad esempio, l'idratazione) hanno influito sulle prestazioni del cluster, controlla gli eventi del cluster Amazon Redshift. Gli eventi del cluster ti informano di eventuali azioni di sostituzione dei nodi e/o di qualsiasi altra azione del cluster eseguita.

Per monitorare il processo di idratazione, utilizza la tabella STV_UNDERREPPED_BLOCKS. I blocchi che richiedono idratazione possono essere recuperati utilizzando la seguente query:

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Nota: La durata del processo di idratazione dipende dal carico di lavoro del cluster. Per misurare l'avanzamento del processo di idratazione del cluster, controlla i blocchi a determinati intervalli.

Per verificare lo stato di un particolare nodo, utilizza la seguente query in modo da confrontarne le prestazioni con altri nodi:

SELECT day
  , node
  , elapsed_time_s
  , sum_rows
  , kb
  , kb_s
  , rank() over (partition by day order by kb_s) AS rank
FROM (
  SELECT DATE_TRUNC('day',start_time) AS day
    , node
    , sum(elapsed_time)/1000000 AS elapsed_time_s
    , sum(rows) AS sum_rows
    , sum(bytes)/1024 AS kb
    , (sum(bytes)/1024)/(sum(elapsed_time)/1000000) AS "kb_s"
  FROM svl_query_report r
    , stv_slices AS s
  WHERE r.slice = s.slice
    AND elapsed_time > 1000000
  GROUP BY day
    , node
  ORDER BY day
    , node
);

Di seguito puoi trovare un esempio di output di una query:

day    node    elapsed_time_s    sum_rows         kb         kb_s  rank
...
4/8/20     0      3390446     686216350489    21570133592    6362    4
4/8/20     2      3842928     729467918084    23701127411    6167    3
4/8/20     3      3178239     706508591176    22022404234    6929    7
4/8/20     5      3805884     834457007483    27278553088    7167    9
4/8/20     7      6242661     433353786914    19429840046    3112    1
4/8/20     8      3376325     761021567190    23802582380    7049    8
...This output indicates that the node 7 processed 19429840046 Kb of data for 6242661 amount of seconds, which is a lot slower than the other nodes.

Il rapporto tra il numero di righe (colonna "sum_rows") e il numero di byte elaborati (colonna "kb") è all'incirca lo stesso. Anche il numero di righe nella colonna "kb_s" corrisponde all'incirca al numero di righe, a seconda delle prestazioni hardware. Se osservi che un particolare nodo elabora meno dati in un determinato periodo di tempo, le prestazioni basse potrebbero indicare un problema dell’hardware di base. Per confermare l'esistenza di un problema dell’hardware di base, esamina il grafico delle prestazioni del nodo.

---