# CPU Este evento ocurre cuando un subproceso está activo en la CPU o espera por la CPU. **Topics** + [Versiones del motor admitidas](#wait-event.cpu.context.supported) + [Contexto](#wait-event.cpu.context) + [Causas probables del aumento de las esperas](#wait-event.cpu.causes) + [Acciones](#wait-event.cpu.actions) ## 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. **Topics** + [Cómo saber cuándo se produce esta espera](#wait-event.cpu.when-it-occurs) + [Métrica de DBloadCPU](#wait-event.cpu.context.dbloadcpu) + [Métrica os.cpuUtilization](#wait-event.cpu.context.osmetrics) + [Causa probable de la programación de la CPU](#wait-event.cpu.context.scheduling) ### 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. **Topics** + [Causas probables de picos repentinos](#wait-event.cpu.causes.spikes) + [Causas probables de alta frecuencia prolongada](#wait-event.cpu.causes.long-term) + [Casos aislados](#wait-event.cpu.causes.corner-cases) ### 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](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md). ## 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. **Topics** + [Investigue si la base de datos es la causa del aumento de la CPU](#wait-event.cpu.actions.db-CPU) + [Determine si el número de conexiones aumentó](#wait-event.cpu.actions.connections) + [Responder a los cambios en la carga de trabajo](#wait-event.cpu.actions.workload) ### 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 [Amazon RDS Proxy ](rds-proxy.md). + 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](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/](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`.