¿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, tenga en cuenta los siguientes enfoques:

• 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 si hay 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

Si observa problemas de rendimiento en su clúster de Amazon Redshift, revise las métricas y los gráficos de rendimiento del clúster. Las métricas y los gráficos de rendimiento del clúster pueden ayudarle a reducir la posible 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 sobre la supervisión de las métricas de rendimiento, consulte Monitoreo de Amazon Redshift mediante las métricas de Amazon CloudWatch.

Consulte el desglose de la ejecución de la carga de trabajo en la consola de Amazon Redshift para revisar determinadas consultas y tiempos de ejecución. 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

Amazon Redshift Advisor ofrece recomendaciones sobre cómo puede mejorar y optimizar el rendimiento del clúster de Amazon Redshift. Amazon Redshift Advisor está disponible en la consola de Amazon Redshift de forma gratuita. Utilice las recomendaciones de Amazon Redshift Advisor para obtener información sobre las posibles áreas de mejora 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 la 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 observa una consulta lenta o ineficiente, compruebe las entradas STL_ALERT_EVENT_LOG. Para recuperar información de la tabla STL_ALERT_EVENT_LOG, utilice 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;

Esta 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.

Este es 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 sobre cómo diagnosticar problemas comunes de uso del disco, 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 sea necesario obtener 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 «suspendidas» 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 sobre el retraso en la ejecución de una consulta, consulte Why is my query planning time so high in 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 transacciones de larga duración afecten al rendimiento de las consultas, tenga en cuenta los siguientes consejos:

• Identifique las sesiones de larga duración y termínelas inmediatamente. Puede utilizar las tablas STL_SESSIONS ySVV_TRANSACTIONS para comprobar si hay transacciones de larga duración.
• Diseñe sus consultas para que Amazon Redshift pueda procesarlas de forma rápida y eficiente.

Nota: Las 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 sobre cómo identificar las sesiones de larga duración que pueden provocar bloqueos de tablas, consulte ¿Cómo puedo detectar y liberar bloqueos en Amazon Redshift?

Compruebe la configuración de administración de cargas de trabajo (WLM)

Dependiendo de la configuración de WLM, una consulta puede empezar a ejecutarse inmediatamente o pasar un tiempo haciendo cola. El objetivo siempre debe ser minimizar 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, utilice la siguiente consulta:

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;

Esta consulta proporciona el número total de transacciones (xid), el tiempo de ejecución, el tiempo de cola y los detalles de la cola de confirmación. Puede comprobar 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, utilice 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;

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

Durante el período de mantenimiento del clúster, se pueden llevar a cabo tareas de mantenimiento como la aplicación de parches, los cambios de configuración interna y el reemplazo de nodos. Si se ha reemplazado un nodo durante el período de mantenimiento, 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. Este proceso se conoce como hidratación. Durante el proceso de hidratación, es posible que el rendimiento del clúster disminuya.

Para identificar qué eventos (como la hidratación) han afectado al rendimiento del clúster, compruebe los eventos del clúster de Amazon Redshift. Los eventos de su clúster le informan de cualquier acción de reemplazo de nodos o de cualquier otra acción de clúster que esté en proceso.

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

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

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

Para comprobar el estado de un nodo concreto, utilice 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
);

Este es un 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
...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.

La relación entre el número de filas (columna «sum_rows») y el número de bytes procesados (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, según el rendimiento del hardware. Si observa que un nodo en particular procesa menos datos durante un período de tiempo, ese bajo rendimiento podría indicar un problema de hardware subyacente. Para confirmar que hay un problema de hardware subyacente, revise el gráfico de rendimiento del nodo.

---