CPU - Amazon Relational Database Service
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

CPU

Este evento ocurre cuando un subproceso está activo en la CPU o espera por la CPU.

Versiones del motor admitidas

Esta información de eventos de espera es relevante para todas las versiones de RDS para PostgreSQL.

Contexto

La unidad de procesamiento central (CPU) es el componente de un ordenador que ejecuta instrucciones. Por ejemplo, las instrucciones de la CPU hacen operaciones aritméticas e intercambian datos en la memoria. Si una consulta aumenta el número de instrucciones que ejecuta a través del motor de base de datos, aumenta el tiempo de ejecución de la consulta. La programación de la CPU consiste en dar tiempo de CPU a un proceso. La programación es orquestada por el núcleo del sistema operativo.

Cómo saber cuándo se produce esta espera

Este evento de espera de CPU indica que un proceso del backend se encuentra activo en la CPU o en espera de la misma. Se sabrá que sucede cuando una consulta muestre la siguiente información:

  • La columna pg_stat_activity.state tiene el valor active.

  • Las columnas wait_event_type y wait_event en pg_stat_activity son null.

Para ver los procesos del backend que se encuentran en uso o en espera de CPU, ejecute la siguiente consulta.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

Métrica de DBloadCPU

La métrica de Información sobre rendimiento para la CPU es DBLoadCPU. El valor de DBLoadCPU puede diferir del valor de la métrica CPUUtilization de Amazon CloudWatch. Esta última métrica se recopila del hipervisor para una instancia de base de datos.

Métrica os.cpuUtilization

Las métricas del sistema operativo de Información sobre rendimiento proporcionan información detallada sobre la utilización de la CPU. Por ejemplo, puede mostrar las siguientes métricas:

  • os.cpuUtilization.nice.avg

  • os.cpuUtilization.total.avg

  • os.cpuUtilization.wait.avg

  • os.cpuUtilization.idle.avg

Información sobre rendimiento informa del uso de la CPU por parte del motor de base de datos como os.cpuUtilization.nice.avg.

Causa probable de la programación de la CPU

El núcleo del sistema operativo (SO) ejecuta la programación de la CPU. Cuando la CPU está activa, es posible que un proceso tenga que esperar para programarse. La CPU está activa mientras realiza los cálculos. También está activa mientras ejecuta un subproceso inactivo, es decir, un subproceso inactivo que espera la E/S de la memoria. Este tipo de E/S domina la carga de trabajo típica de una base de datos.

Es probable que los procesos esperen a que se programe una CPU cuando se cumplen las siguientes condiciones:

  • La métrica CloudWatch CPUUtilization está cerca del 100 por ciento.

  • La carga media es mayor que el número de vCPU, lo que indica una carga pesada. Puede encontrar la métrica loadAverageMinute en la sección de métricas del sistema operativo en Información sobre rendimiento.

Causas probables del aumento de las esperas

Cuando el evento de espera de la CPU ocurre más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas pueden ser las siguientes.

Causas probables de picos repentinos

Las causas más probables de picos repentinos son las siguientes:

  • La aplicación abrió demasiadas conexiones simultáneas a la base de datos. Este escenario se conoce como “tormenta de conexiones”

  • La carga de trabajo de la aplicación ha cambiado de alguna de las siguientes maneras:

    • Nuevas consultas

    • Un aumento del tamaño del conjunto de datos

    • Mantenimiento o creación de índices

    • Nuevas funciones

    • Nuevos operadores

    • Aumento de la ejecución de consultas en paralelo

  • Los planes de ejecución de sus consultas han cambiado. En algunos casos, un cambio puede provocar un aumento de los búferes. Por ejemplo, la consulta utiliza ahora un escaneo secuencial cuando antes utilizaba un índice. En este caso, las consultas necesitan más CPU para lograr el mismo objetivo.

Causas probables de alta frecuencia prolongada

Las causas más probables de eventos que se repiten durante un periodo prolongado:

  • Demasiados procesos de backend se ejecutan de forma simultánea en la CPU. Estos procesos pueden llegar a ser procesos de trabajo paralelos.

  • Las consultas tienen un rendimiento subóptimo porque necesitan un gran número de búferes.

Casos aislados

Si ninguna de las causas probables resulta ser la causa real, es posible que se produzcan las siguientes situaciones:

  • La CPU está intercambiando procesos de entrada y salida.

  • La CPU podría gestionar las entradas de la tabla de páginas si se ha desactivado la función de páginas enormes. Esta característica de administración de la memoria está habilitada de forma predeterminada para todas las clases de instancias de base de datos que no sean de la clase de instancia de base de datos micro, pequeña y mediana. Para obtener más información, consulte Páginas enormes para RDS for PostgreSQL .

Acciones

Si el evento de espera de CPU domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Responda a este evento solo cuando el rendimiento se deteriore.

Investigue si la base de datos es la causa del aumento de la CPU

Examine la métrica os.cpuUtilization.nice.avg en Información sobre rendimiento. Si este valor es mucho menor que el uso de la CPU, los procesos ajenos a la base de datos son los que más contribuyen a la CPU.

Determine si el número de conexiones aumentó

Examine la métrica DatabaseConnections en Amazon CloudWatch. La acción a tomar depende de si el número aumentó o disminuyó durante el periodo de aumento de los eventos de espera de la CPU.

Las conexiones aumentaron

Si el número de conexiones aumentó, compare el número de procesos de backend que consumen CPU con el número de vCPU. Los siguientes escenarios son posibles:

  • El número de procesos de backend que consumen CPU es menor que el número de vCPU.

    En este caso, el número de conexiones no es un problema. Sin embargo, puede intentar reducir la utilización de la CPU.

  • El número de procesos de backend que consumen CPU es mayor que el número de vCPU.

    En este caso, considere las siguientes opciones:

    • Disminuya el número de procesos backend conectados a la base de datos. Por ejemplo, implemente una solución de agrupación de conexiones, como el proxy RDS. Para obtener más información, consulte Uso de Amazon RDS Proxy .

    • Actualice el tamaño de su instancia para obtener un mayor número de vCPU.

    • Redirija algunas cargas de trabajo de solo lectura a nodos lectores, si procede.

Las conexiones no aumentaron

Examine las métricas de blks_hit en Información sobre rendimiento. Busque una correlación entre el aumento de blks_hit y el uso de la CPU. Los siguientes escenarios son posibles:

  • El uso de la CPU y blks_hit están correlacionados.

    En este caso, encuentre las principales instrucciones SQL que están relacionadas con el uso de la CPU y busque los cambios de plan. Puede utilizar cualquiera de las siguientes técnicas:

    • Explicar los planes manualmente y compararlos con el plan de ejecución esperado.

    • Buscar un aumento en los aciertos de bloque por segundo y en los aciertos de bloque local por segundo. En la sección Top SQL (SQL principal) del panel de Información sobre rendimiento, elija Preferences (Preferencias).

  • El uso de la CPU y blks_hit no están correlacionados.

    En este caso, determine si se produce alguna de las siguientes situaciones:

    • La aplicación se conecta y desconecta con rapidez de la base de datos.

      Diagnostique este comportamiento mediante la activación de log_connections y log_disconnections, y luego analice los registros de PostgreSQL. Considere utilizar el analizador de registros pgbadger. Para obtener más información, consulte https://github.com/darold/pgbadger.

    • El sistema operativo está sobrecargado.

      En este caso, Información sobre rendimiento muestra que los procesos del backend consumen la CPU durante más tiempo del habitual. Busque pruebas en las métricas de Información sobre rendimiento os.cpuUtilization o en la métrica CloudWatch CPUUtilization. Si el sistema operativo está sobrecargado, consulte las métricas de Monitoreo mejorado para hacer un diagnóstico más profundo. Específicamente, observe la lista de procesos y el porcentaje de CPU que consume cada proceso.

    • Las instrucciones SQL más importantes son las que consumen demasiada CPU.

      Examine las instrucciones que se relacionan con el uso de la CPU para ver si pueden utilizar menos CPU. Ejecute un comando EXPLAIN, y céntrese en los nodos del plan que tienen el mayor impacto. Considere utilizar un visualizador de planes de ejecución de PostgreSQL. Para probar esta herramienta, consulte http://explain.dalibo.com/.

Responder a los cambios en la carga de trabajo

Si la carga de trabajo cambió, busque los siguientes tipos de cambios:

Nuevas consultas

Verifique si las nuevas consultas son las esperadas. Si es así, asegúrese de que los planes de ejecución y el número de ejecuciones por segundo son los esperados.

Aumento del tamaño del conjunto de datos

Determine si la partición, si no se ha implementado todavía, podría ayudar. Esta estrategia podrá reducir el número de páginas que debe recuperar una consulta.

Mantenimiento o creación de índices

Verifique si el programa de mantenimiento es el previsto. Una práctica recomendada es programar las actividades de mantenimiento fuera de los picos de actividad.

Nuevas funciones

Verifique si estas funciones se comportan como se espera durante las pruebas. En concreto, verifique si el número de ejecuciones por segundo es el esperado.

Nuevos operadores

Verifique si su rendimiento es el esperado durante las pruebas.

Aumento de la ejecución de consultas paralelas

Determine si se ha producido alguna de las siguientes situaciones:

  • Las relaciones o los índices implicados han crecido repentinamente en tamaño de modo que difieren significativamente de min_parallel_table_scan_size o min_parallel_index_scan_size.

  • Se hicieron cambios recientes en parallel_setup_cost o parallel_tuple_cost.

  • Se hicieron cambios recientes en max_parallel_workers o max_parallel_workers_per_gather.