¿Cómo soluciono los problemas de uso excesivo de la CPU en Amazon Redshift?

9 minutos de lectura
0

Veo un uso excesivo de la CPU en mi clúster de Amazon Redshift. ¿Por qué ocurre esto y qué prácticas recomendadas hay para reducir el uso de la CPU?

Breve descripción

Amazon Redshift está diseñado para utilizar todos los recursos disponibles al ejecutar las consultas. Esto significa que puede esperar ver picos en el uso de la CPU en su clúster de Redshift. El aumento de la utilización de la CPU puede depender de factores como la carga de trabajo del clúster, los datos sesgados y sin clasificar o las tareas del nodo líder.

Sin embargo, si el uso de la CPU afecta al tiempo de consulta, considere los siguientes enfoques:

  • Revise la carga de trabajo del clúster de Redshift.
  • Mantenga la limpieza de sus datos.
  • Actualice el diseño de tabla.
  • Compruebe si hay actualizaciones de mantenimiento.
  • Compruebe si hay picos en el uso de la CPU de su nodo líder.
  • Utilice Amazon CloudWatch para supervisar los picos de uso de la CPU.

Resolución

Revise la carga de trabajo del clúster de Redshift

Los siguientes factores pueden afectar al uso de la CPU en su clúster de Redshift:

  • Una mayor carga de trabajo (debido a que se ejecutan más consultas). El aumento de la carga de trabajo aumenta el número de conexiones a la base de datos, lo que provoca una mayor concurrencia de consultas.
  • El mayor número de consultas simultáneas afecta a la contención de recursos, al tiempo de espera del bloqueo y al tiempo de espera de las colas de administración de cargas de trabajo (WLM).
  • Más conexiones a bases de datos. Esto puede ser el resultado de sesiones inactivas presentes en el clúster. Las sesiones inactivas pueden provocar problemas adicionales de contención de bloqueos.

Mientras se ejecutan las consultas, recupere la información de bloqueo. Para identificar las sesiones de larga duración, utilice la siguiente consulta SQL:

select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' as "duration"
from svv_transactions where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;<br>

A continuación, ejecute PG_TERMINATE_BACKEND para detener cualquier transacción de larga duración. Para evitar que estas sesiones permanezcan abiertas, asegúrese de cerrar todas las transacciones. Por ejemplo, asegúrese de que todas las transacciones que comiencen con una instrucción BEGIN vayan acompañadas de una instrucción END o COMMIT.

A continuación, ejecute la siguiente consulta SQL para identificar las consultas que consumen mucha CPU:

select stq.userid, stq.query, trim(stq.label) as label, stq.xid, stq.pid, svq.service_class,
query_cpu_usage_percent as "cpu_%",starttime, endtime, datediff(s,starttime, endtime) as duration_s,
substring(stq.querytxt,1,100) as querytext from stl_query stq
join svl_query_metrics svq on stq.query=svq.query
where query_cpu_usage_percent is not null and starttime > sysdate - 1
order by query_cpu_usage_percent desc;

Para analizar los pasos de ejecución a nivel de segmento e intervalo de cada consulta, ejecute la siguiente consulta:

select query, segment, step, label ,is_rrscan as rrS, is_diskbased as disk, is_delayed_scan as DelayS, min(start_time) as starttime, max(end_time) as endtime, datediff(ms, min(start_time), max(end_time)) as "elapsed_msecs", sum(rows) as row_s , sum(rows_pre_filter) as rows_pf, CASE WHEN sum(rows_pre_filter) = 0 THEN 100 ELSE sum(rows)::float/sum(rows_pre_filter)::float*100 END as pct_filter, SUM(workmem)/1024/1024 as "Memory(MB)", SUM(bytes)/1024/1024 as "MB_produced" from svl_query_report where query in (<query_ids>) group by query, segment, step, label , is_rrscan, is_diskbased , is_delayed_scan order by query, segment, step, label;

Para obtener más información sobre cómo ajustar estas consultas, consulte Top 10 performance tuning techniques for Amazon Redshift.

También puede usar la vista wlm_query_trend_hourly para revisar el patrón de carga de trabajo del clúster de Redshift. A continuación, determine cuál de los siguientes enfoques puede ayudarle a reducir el tiempo de espera en las colas:

  • Reduzca la concurrencia de consultas por cola para proporcionar más memoria a cada ranura de consulta. Esta reducción ayuda a que las consultas que requieren más memoria se ejecuten de manera más eficiente.
  • Habilite la aceleración de consultas cortas (SQA) para priorizar las consultas de ejecución corta sobre las de ejecución larga.
  • Escale el clúster de Redshift para adaptarse al aumento de la carga de trabajo. Escalar un clúster proporciona más memoria y potencia de cálculo, lo que puede ayudar a que las consultas se ejecuten con mayor rapidez. Para obtener más información, consulte How do I resize a Redshift cluster?

Mantenga la limpieza de sus datos

La limpieza de los datos se mide por el porcentaje de estadísticas obsoletas y filas sin clasificar presentes en una tabla. Un alto porcentaje de ambas puede provocar que el optimizador de consultas genere un plan de ejecución en el que las consultas se ejecuten de manera ineficiente al hacer referencia a las tablas. Los datos sin clasificar pueden hacer que las consultas escaneen bloques de datos innecesarios, lo que requiere operaciones de E/S adicionales. Una consulta de bajo rendimiento afecta negativamente al uso de la CPU del clúster de Redshift.

Utilice la vista del sistema SVV_TABLE_INFO para recuperar stats_off y los datos porcentuales sin clasificar de una tabla. Estos porcentajes deben permanecer próximos a 0. Si los porcentajes son altos, ejecute la utilidad de esquemas Analyze & Vacuum del repositorio GitHub de los Laboratorios de AWS para actualizar las tablas.

Actualice el diseño de su tabla

El diseño de la tabla se rige por las claves de ordenación, el estilo de distribución y la clave de distribución designados. La clave de distribución y el estilo de distribución determinan cómo se distribuyen los datos en los nodos.

Una clave de distribución o un estilo de distribución inadecuados pueden provocar un sesgo de distribución en los nodos. Para reducir el sesgo en la distribución de datos, elija el estilo de distribución y la clave de ordenación en función de los patrones de consulta y los predicados. La clave de distribución debe admitir las condiciones de unión en las consultas y columnas con una cardinalidad alta. Una selección adecuada de la clave de distribución puede ayudar a que las consultas realicen uniones de combinaciones en lugar de uniones de hash o de bucles anidados, lo que, en última instancia, afecta a la cantidad de tiempo en el que se ejecutan las consultas.

Para identificar tablas con una distribución sesgada, utilice el script table_inspector.sql. A continuación, utilice el manual de diseño de tablas de Amazon Redshift para elegir las claves de ordenación, las claves de distribución y los estilos de distribución más adecuados para su tabla.

Compruebe si hay actualizaciones de mantenimiento

Amazon Redshift almacena en caché el código compilado, lo que permite a las consultas reutilizar el código de los segmentos ejecutados anteriormente. A continuación, la memoria caché se borra durante cualquier actualización de mantenimiento. Como resultado, las consultas que se ejecuten por primera vez después de una actualización de parche pasarán algún tiempo compilándose. Esta sobrecarga de compilación puede aumentar el uso de la CPU de un clúster de Redshift.

Utilice la siguiente consulta SQL para comprobar cuántos segmentos se compilan cada hora:

select "hour", count(query) total_queries, count(case when is_compiled='Y' then 1 else null end ) as queries_compiled_count, sum(segements_count) total_segments_count, sum(segments_compiled_count) total_segments_compiled_count from
(
  select q.query, date_trunc('h',q.starttime) as "hour", q.starttime, q.endtime, q.aborted, (case when compiled_queries.segments_compiled_count = 0 then 'N' ELSE 'Y' end) is_compiled, compiled_queries.segements_count, compiled_queries.segments_compiled_count
  from stl_query q
  left join (select query, count(segment) segements_count, sum(compile) segments_compiled_count from svl_compile group by query) compiled_queries on q.query = compiled_queries.query
  where q.userid > 1
  and q.starttime > trunc(sysdate) -7
)
group by "hour"
order by "hour";

Compruebe si hay picos en el uso de la CPU de su nodo líder

Las tareas del nodo líder, como analizar y optimizar las consultas, generar código compilado y agregar los resultados de los nodos de procesamiento, consumen recursos de la CPU. Este consumo conduce a un mayor uso de la CPU del nodo líder. El uso de la CPU del nodo líder también puede aumentar si las consultas hacen muchas referencias a las tablas del catálogo del sistema o realizan funciones exclusivas del nodo líder.

Si el aumento en el uso de la CPU se debe a un nodo líder, consulte la sección Eventos de la consola de Amazon Redshift. Compruebe si se ha realizado algún tipo de mantenimiento en su clúster de Redshift. Utilice la consulta SQL que se proporciona en Buscar actualizaciones de mantenimiento para comprobar si se están compilando más segmentos de lo habitual.

Utilice CloudWatch para supervisar los picos de uso de la CPU

Utilice las métricas de CloudWatch para comparar los picos entre CPUutilization y las conexiones a bases de datos. Analice el rendimiento de la carga de trabajo al consultar el gráfico de desglose de la ejecución de la carga de trabajo. El gráfico de desglose de la ejecución de la carga de trabajo muestra las etapas en las que las consultas dedican más tiempo.

Para identificar las 100 consultas principales que consumen la mayor cantidad de CPU durante un tiempo específico, utilice la siguiente consulta:

select qms.*, substring(q.querytxt,1,100) qtxt
from svl_query_metrics_summary qms
join stl_query q on q.query=qms.query
where q.starttime > sysdate - 1
and q.userid>1
order by qms.query_cpu_time desc nulls last limit 100;

Para recuperar una lista de las consultas que consumen más recursos cuando la CPU alcanza el 100 %, utilice la siguiente consulta:

select a.userid, service_class, a.query, b.pid, b.xid, a.starttime, slices, max_rows, max_blocks_read, max_blocks_to_disk, max_query_scan_size, segment, round(max_cpu_time/(max_run_time*1.0)*100,2) as max_cpu_pcnt, round(cpu_time/(run_time*1.0)*100,2) as cpu_pcnt, max_cpu_time, max_run_time, case when segment > -1 then 'segment' else 'query' end as metric_lvl, text from pg_catalog.stv_query_metrics a left join stv_inflight b using (query) where step_type=-1 order by query, segment;

Para comprobar la cantidad de datos que procesa cada nodo, ejecute la siguiente consulta:

select iq.day_d, sl.node, sum(iq.elapsed_ms) as elapsed, sum(iq.bytes) as bytes from (select start_time::date as day_d, slice,query,segment,datediff('ms',min(start_time),max(end_time)) as elapsed_ms, sum(bytes) as bytes from svl_query_report where end_time > start_time group by 1,2,3,4) iq join stv_slices as sl on (sl.slice = iq.slice) group by 1,2 order by 1 desc, 3 desc;

Puede utilizar las reglas de monitoreo de las consultas (QMR) para identificar y registrar cualquier consulta mal diseñada. Por ejemplo, las reglas de QMR se pueden definir para registrar consultas que consumen un alto uso de la CPU o un tiempo de ejecución prolongado.


OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 años