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

9 minuti di lettura
0

Desidero risolvere un problema o migliorare le prestazioni delle query nel cluster Amazon Redshift.

Breve descrizione

Se riscontri problemi di prestazioni nel cluster Amazon Redshift, completa le seguenti attività:

  • 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 problemi di blocco e di sessioni o transazioni di lunga durata.
  • 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

Esamina le metriche e i grafici delle prestazioni del cluster per trovare la causa principale del 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 un conflitto di risorse sul cluster Amazon Redshift. Per ulteriori informazioni, consulta Monitoring Amazon Redshift using Amazon CloudWatch metrics.

Controlla la suddivisione dell'esecuzione del carico di lavoro nella console Amazon Redshift per esaminare query e runtime specifiche. Ad esempio, se noti un aumento dei tempi di pianificazione delle query, è possibile che una query sia in attesa di un blocco.

Controllo dei consigli di Amazon Redshift Advisor

Utilizza i consigli di Amazon Redshift Advisor per conoscere le aree di miglioramento potenziali del 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

Quando viene eseguita una query, Amazon Redshift esamina le prestazioni della query e indica se la query 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. I consigli vengono registrati in STL_ALERT_EVENT_LOG, una tabella di sistema interna.

Se 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 è riportato un esempio di output della query e delle 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

Per verificare le prestazioni delle query, controlla 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 nidificato è il tipo di join meno efficace. Poiché i loop nidificati aumentano notevolmente il tempo di esecuzione delle query, è bene cercare di evitarli annidati.

Per facilitare la diagnosi del problema,identifica le query che eseguono i loop nidificati. Per ulteriori informazioni, consulta Come posso risolvere i problemi relativi all'utilizzo elevato o completo del disco con Amazon Redshift?

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

Prima di eseguire una query sul cluster, Amazon Redshift potrebbe acquisire blocchi a livello di tabella sulle tabelle coinvolte nelle esecuzioni delle query. A volte, sembra che le query non stiano rispondendo o che si verifichi un picco nel runtime delle query. Se si verifica un picco nel runtime della query, la causa potrebbe essere un problema di blocco. Per ulteriori informazioni, consulta Perché il tempo di pianificazione delle query è così elevato in Amazon Redshift?

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

A volte, una query non risponde più a causa di una transazione di lunga durata. Per evitare che sessioni o transazioni di lunga durata influiscano sulle prestazioni delle query, esegui le seguenti azioni:

  • Utilizza le tabelle STL\ _SESSIONS e SVV\ _TRANSACTIONS per verificare la presenza di sessioni e transazioni di lunga durata e quindi terminarle.
  • Progetta le query in modo che Amazon Redshift possa elaborarle in modo rapido ed efficace.

Nota: le sessioni o le transazioni di lunga durata influiscono anche sull'operazione VACUUM per recuperare spazio su disco e causano un aumento del numero di righe fantasma o non salvate. Le righe fantasma scansionate dalle query possono influire sulle prestazioni delle query.

Per ulteriori informazioni, consulta Come posso rilevare e sbloccare i blocchi in Amazon Redshift?

Verifica della configurazione WLM

A seconda della configurazione della gestione del carico di lavoro (WLM), l’esecuzione di una query potrebbe iniziare subito oppure la query potrebbe essere messa in coda. Riduci al minimo il tempo di attesa per l'esecuzione di una query. Se stai cercando di definire le 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_pcntFROM
(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), runtime, tempo in coda e 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;

Nota: 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 nodo di cluster

Se un nodo è stato sostituito durante una 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. Durante il processo, le prestazioni del cluster potrebbero diminuire.

Per identificare gli eventi che hanno influito sulle prestazioni del cluster, controlla gli eventi del cluster Amazon Redshift.

Per monitorare il processo di ripristino dei dati, utilizza la tabella STV_UNDERREPPED_BLOCKS. Esegui la seguente query per recuperare i blocchi che richiedono il ripristino dei dati:

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Nota: la durata del processo di ripristino dei dati dipende dal carico di lavoro del cluster. Per misurare l'avanzamento del processo di ripristino dei dati 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
);

Esempio di output della 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

Nota: l'output precedente mostra che il nodo 7 ha elaborato 19429840046 KB di dati per 6242661 secondi. È quindi molto più lento rispetto agli altri nodi.

Il rapporto tra il numero di righe nella colonna sum\ _rows e il numero di byte elaborati nella colonna kb è all'incirca lo stesso. Il numero di righe nella colonna kb_s corrisponde all'incirca al numero di righe della colonna sum_rows, a seconda delle prestazioni hardware. Se un nodo elabora meno dati in un dato periodo di tempo, la causa potrebbe essere un problema hardware. Per confermare l'esistenza di un problema ’hardware, esamina il grafico delle prestazioni del nodo.

AWS UFFICIALE
AWS UFFICIALEAggiornata un anno fa