¿Cómo soluciono los problemas de rendimiento de clústeres o consultas en Amazon Redshift?

Breve descripción

Si tiene problemas de rendimiento en su clúster de Amazon Redshift, haga lo siguiente:

• Supervise las métricas de rendimiento de su clúster.
• Consulte las recomendaciones de Amazon Redshift Advisor.
• Revise las alertas de ejecución de consultas y el uso excesivo del disco.
• Compruebe si hay problemas de bloqueo y sesiones o transacciones de larga duración.
• Compruebe la configuración de administración de cargas de trabajo (WLM).
• Compruebe el mantenimiento y el rendimiento del hardware del nodo del clúster.

Resolución

Supervise las métricas de rendimiento de su clúster

La revisión de las métricas y los gráficos de rendimiento del clúster puede ayudarle a encontrar la causa raíz de la degradación del rendimiento. Puede ver los datos de rendimiento en la consola de Amazon Redshift para comparar el rendimiento del clúster a lo largo del tiempo.

Un aumento en estas métricas puede indicar una mayor carga de trabajo y una mayor contención de recursos en su clúster de Amazon Redshift. Para obtener más información, consulte Monitoreo de Amazon Redshift mediante las métricas de CloudWatch.

Consulte el desglose de la ejecución de la carga de trabajo en la consola de Amazon Redshift para revisar las consultas y los tiempos de ejecución específicos. Por ejemplo, si observa un aumento en el tiempo de planificación de consultas, podría ser un indicio de que una consulta está esperando un bloqueo.

Consulte las recomendaciones de Amazon Redshift Advisor

Utilice las recomendaciones de Amazon Redshift Advisor para obtener información sobre las posibles mejoras de su clúster. Las recomendaciones se basan en patrones de uso comunes y en las prácticas recomendadas de Amazon Redshift.

Revise las alertas de ejecución de consultas y el uso excesivo del disco

Durante la ejecución de una consulta, Amazon Redshift toma nota del rendimiento de la consulta e indica si la consulta se ejecuta de manera eficiente. Si la consulta se identifica como ineficiente, Amazon Redshift anota el identificador de la consulta y ofrece recomendaciones para mejorar su rendimiento. Estas recomendaciones se registran en STL_ALERT_EVENT_LOG, una tabla interna del sistema.

Si la consulta es lenta o ineficaz, compruebe las entradas STL_ALERT_EVENT_LOG. Para recuperar información de la tabla STL_ALERT_EVENT_LOG, ejecute la siguiente consulta:

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;

La consulta muestra los identificadores de consulta y los problemas y apariciones de problemas más comunes de la consulta que se ejecuta en el clúster.

A continuación se muestra un ejemplo de resultado de la consulta y la información que describe por qué se ha activado la alerta:

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

Revise el rendimiento de las consultas comprobando las consultas de diagnóstico para ajustarlas. Asegúrese de que las operaciones de consulta estén diseñadas para ejecutarse de manera eficiente. Por ejemplo, no todas las operaciones de unión son eficaces. Una unión de bucle anidado es el tipo de unión menos eficaz y debe evitarse si es posible, ya que este tipo aumenta considerablemente el tiempo de ejecución de la consulta.

Identifique las consultas que realizan los bucles anidados para ayudarle a diagnosticar el problema. Para obtener más información, consulte ¿Cómo puedo solucionar problemas de uso excesivo o completo del disco con Amazon Redshift?

Compruebe si hay problemas de bloqueo y sesiones o transacciones de larga duración

Antes de ejecutar una consulta en el clúster, es posible que Amazon Redshift adquiera bloqueos a nivel de tabla en las tablas que participan en la ejecución de la consulta. Puede haber casos en los que las consultas aparezcan como que no responden o que se produzca un aumento en el tiempo de ejecución de las consultas. Si observa un aumento en el tiempo de ejecución de la consulta, la causa podría ser un problema de bloqueo. Para obtener más información, consulte ¿Por qué es tan alto el tiempo de planificación de mi consulta en Amazon Redshift?

Si la tabla está bloqueada actualmente por otro proceso o consulta, la consulta no puede continuar. Como resultado, su consulta no aparecerá en la tabla STV_INFLIGHT. En su lugar, la consulta en ejecución aparecerá en la tabla STV_RECENTS.

A veces, una consulta suspendida se debe a una transacción de larga duración. Para evitar que las sesiones o transacciones de larga duración afecten al rendimiento de las consultas, tenga en cuenta los siguientes consejos:

• Utilice las tablas STL_SESSIONS y SVV_TRANSACTIONS para comprobar si hay sesiones y transacciones de larga duración y, a continuación, finalizarlas.
• Diseñe sus consultas para que Amazon Redshift pueda procesarlas de forma rápida y eficiente.

Nota: Las sesiones o transacciones de larga duración también afectan a la capacidad de VACUUM de recuperar espacio en disco, lo que provoca un mayor número de filas fantasmas o filas sin confirmar. Las filas fantasma que se escanean mediante consultas pueden afectar al rendimiento de las consultas.

Para obtener más información, consulte ¿Cómo puedo detectar y liberar bloqueos en Amazon Redshift?

Compruebe la configuración de WLM

Dependiendo de la configuración de WLM, una consulta puede empezar a ejecutarse inmediatamente o permanecer más tiempo en cola. Minimice la cantidad de tiempo que una consulta permanece en cola para su ejecución. Si quiere definir sus colas, compruebe la asignación de memoria de WLM.

Para comprobar las colas de WLM de un clúster durante unos días, ejecute la siguiente consulta:

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;

Esta consulta proporciona el número total de transacciones, o xid, el tiempo de ejecución, el tiempo de cola y los detalles de la cola de confirmación. Compruebe los detalles de la cola de confirmación para ver si las confirmaciones frecuentes afectan al rendimiento de la carga de trabajo.

Para comprobar los detalles de las consultas que se ejecutan en un momento determinado, ejecute la siguiente consulta:

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: Sustituya 2011-12-20 13:45:00 por la fecha y hora específicas en las que desea comprobar si hay consultas en cola y completadas.

Revise el rendimiento del hardware de su nodo de clúster

Si se ha reemplazado un nodo durante un período de mantenimiento del clúster, es posible que el clúster esté disponible en breve. Sin embargo, puede que los datos tarden un tiempo en restaurarse en el nodo reemplazado. Durante este proceso, es posible que el rendimiento del clúster disminuya.

Para identificar qué eventos han afectado al rendimiento del clúster, compruebe los eventos del clúster de Amazon Redshift.

Para supervisar el proceso de restauración de datos, utilice la tabla STV_UNDERREPPED_BLOCKS. Los bloques que requieren una restauración de datos se pueden recuperar mediante la siguiente consulta:

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Nota: La duración del proceso de restauración de datos depende de la carga de trabajo del clúster. Para medir el progreso del proceso de restauración de datos de su clúster, compruebe los bloques a intervalos determinados.

Para comprobar el estado de un nodo concreto, ejecute la siguiente consulta para comparar su rendimiento con el de otros nodos:

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
);

Ejemplo del resultado de una consulta:

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: El resultado anterior muestra que el nodo 7 ha procesado 19429840046 KB de datos durante 6242661 segundos. Esto es mucho más lento que el resto de los nodos.

La relación entre el número de filas de la columna sum_rows y el número de bytes procesados de la columna kb es aproximadamente la misma. El número de filas de la columna kb_s también es aproximadamente el mismo que el número de filas de la columna sum_rows, según el rendimiento del hardware. Si un nodo procesa menos datos durante un período de tiempo, es posible que haya un problema de hardware subyacente. Para comprobar si hay un problema de hardware subyacente, revise el gráfico de rendimiento del nodo.