Saltar al contenido

¿Cómo soluciono los errores «Statement timeout» en las consultas que se ejecutan en mi clúster de bases de datos compatible con Aurora PostgreSQL?

5 minutos de lectura
0

Quiero solucionar los errores de tiempo de espera de las instrucciones de consultas que se ejecutan en mi clúster de base de datos (DB) de la edición de Amazon Aurora PostgreSQL.

Solución

Importante: Información de rendimiento llegará al final de su ciclo de vida el 30 de noviembre de 2026. Puedes actualizar al modo avanzado de Database Insights antes del 30 de junio de 2026. Si no actualizas, los clústeres de bases de datos que utilizan Información de rendimiento adoptarán de forma predeterminada el modo estándar de Database Insights. Solo el modo avanzado de Database Insights admitirá los planes de ejecución y el análisis bajo demanda. Si los clústeres utilizan el modo estándar de forma predeterminada, es posible que no puedas usar estas características en la consola. Para activar el modo avanzado, consulta Activación del modo avanzado de Database Insights para Amazon RDS y Activación del modo avanzado de Database Insights para Amazon Aurora.

Si las consultas no se ejecutan dentro del tiempo especificado por el parámetro statement_timeout, el parámetro ** statement_timeout** cancela la consulta. Verás el siguiente mensaje de error:

«ERROR: canceling statement due to statement timeout.»

Para solucionar este error, sigue estos pasos.

Comprobación del parámetro statement_timeout configurado

Para comprobar el parámetro statement_timeout en el grupo de parámetros del clúster de base de datos o en el grupo de parámetros de base de datos, ejecuta la consulta SELECT:

SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'statement_timeout';

Resultado esperado:

       name        | setting | unit | context |       source
-------------------+---------+------+---------+--------------------
 statement_timeout | 5000    | ms   | user    | configuration file

Nota: En el resultado del ejemplo, el parámetro statement_timeout tiene un valor de 5000 milisegundos. El campo «origen» muestra el «archivo de configuración», que indica que el parámetro se ha establecido en el nivel del grupo de parámetros del clúster.

A continuación, comprueba el parámetro statement_timeout a nivel de rol y de base de datos.

Para comprobar las configuraciones a nivel de rol para todos los roles del clúster de base de datos, ejecuta la siguiente consulta:

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting s
JOIN pg_roles r ON r.oid = s.setrole
LEFT JOIN pg_database d ON d.oid = s.setdatabase
WHERE s.setconfig::text LIKE '%statement_timeout%'
ORDER BY r.rolname;

Para comprobar las configuraciones a nivel de base de datos de todas las bases de datos del clúster, ejecuta la siguiente consulta:

SELECT d.datname, rs.setconfig
FROM pg_db_role_setting rs
JOIN pg_database d ON d.oid = rs.setdatabase
WHERE rs.setrole = 0;

Revisa el resultado para identificar cualquier configuración statement_timeout establecida a nivel de rol o base de datos que pueda anular la configuración a nivel de clúster.

Nota: Los parámetros statement_timeout que definas con ALTER ROLE SET no se heredan de los roles secundarios. Si configuras el parámetro statement_timeout para un rol, solo podrás usar el parámetro cuando inicies sesión en ese rol. Para obtener más información, consulta ALTER ROLE en el sitio web de PostgreSQL.

Identificación de las consultas SQL canceladas

Consulta el archivo de registro de errores de PostgreSQL y, a continuación, determina si el parámetro log_min_error_statement se ha establecido en ERROR o en una gravedad inferior. Después de identificar la instrucción que devolvió el error, busca los nombres de tabla y SQL con errores. Para obtener más información, consulta Descripción del parámetro log_line_prefix.

Identificación de la causa de la larga duración de la ejecución de las consultas

Si ves que la consulta SQL tiene errores, usa CloudWatch Database Insights para identificar las transacciones bloqueadas.

Para usar CloudWatch Database Insights para analizar el rendimiento, sigue estos pasos:

  1. Abre la consola de Amazon Relational Database Service (Amazon RDS).
  2. En el panel de navegación, selecciona Bases de datos.
  3. Selecciona tu clúster de base de datos de Aurora PostgreSQL.
  4. Selecciona la pestaña Supervisión.
  5. Selecciona Ver detalles en Información de rendimiento.
  6. Revisa la carga de la base de datos. Puedes agrupar la carga de la base de datos por eventos de espera, consultas SQL, hosts o usuarios para identificar las transacciones bloqueadas.

Si el problema se reproduce de forma coherente, configura el parámetro log_min_duration_statement en tu instancia de base de datos y usa el módulo auto_explain. Para obtener más información, consulta ¿Cómo puedo registrar los planes de ejecución de las consultas para Amazon RDS PostgreSQL o Aurora PostgreSQL para ajustar el rendimiento de las consultas?

Puedes usar los comandos EXPLAIN y EXPLAIN ANALYZE para obtener el plan de ejecución de la consulta. Para más información, consulta ¿Cómo puedo identificar y solucionar los problemas de rendimiento y las consultas de ejecución lenta en mi instancia de base de datos compatible con Amazon RDS para PostgreSQL o Aurora PostgreSQL?

Comprobación de si hay filas inactivas en las tablas de origen

Las filas o tuplas inactivas pueden aumentar el tiempo de SELECT. Para comprobar si hay un gran número de filas inactivas en las tablas de origen, ejecuta la siguiente consulta:

SELECT * FROM pg_stat_user_tables WHERE relname = 'table_name';

Nota: Sustituye table_name por el nombre de la tabla de origen.

Información relacionada

How do I end long-running queries in my Amazon RDS for PostgreSQL or Aurora PostgreSQL-Compatible DB instance? (¿Cómo finalizo las consultas de larga duración en mi instancia de base de datos de Amazon RDS para PostgreSQL o de Aurora compatible con PostgreSQL?)

¿Cómo identifico el elemento que ha bloqueado una consulta en mi instancia de base de datos PostgreSQL o Aurora PostgreSQL de Amazon RDS?

OFICIAL DE AWSActualizada hace 5 meses