Compartir vía

Solución de problemas de uso elevado de IOPS en Azure Database for PostgreSQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

En este artículo se muestra cómo identificar rápidamente la causa principal del uso elevado de IOPS (operaciones de entrada y salida por segundo) y proporciona acciones correctivas para controlar el uso de IOPS cuando se usa Servidor flexible de Azure Database for PostgreSQL.

En este artículo aprenderá a:

  • Acerca de las guías de solución de problemas para identificar y obtener recomendaciones para mitigar las causas principales.
  • Use herramientas para identificar el uso elevado de entrada/salida (E/S), como Azure Metrics, Almacén de consultas y pg_stat_statements.
  • Identifique las causas principales, como consultas de larga duración, programación de puntos de control, el proceso de demonio de vaciado automático disruptivo y el uso elevado del almacenamiento.
  • Resuelva el uso elevado de E/S con Explain Analyze, ajuste los parámetros de servidor relacionados con los puntos de control y ajuste el demonio de vaciado automático.

Guías de solución de problemas

Puede encontrar las guías de solución de problemas de características que están disponibles en el portal del servidor flexible de Azure Database for PostgreSQL la causa principal probable y las recomendaciones para mitigar el escenario de uso elevado de IOPS. Para ver cómo configurar las guías de solución de problemas para usarlas, siga las guías de solución de problemas de configuración.

Herramientas para identificar el uso elevado de E/S

Considere las siguientes herramientas para identificar el uso elevado de E/S.

Métricas de Azure

Azure Metrics es un buen punto de partida para comprobar el uso de E/S en una fecha y período definidos. Las métricas dan información sobre el tiempo durante el cual la utilización de E/S es alta. Compara los grafos de IOPS de escritura, IOPS de lectura, rendimiento de lectura y rendimiento de escritura para encontrar los momentos en que la carga de trabajo está ocasionando un uso elevado de E/S. Para la supervisión proactiva, puede configurar alertas en las métricas. Para obtener instrucciones paso a paso, consulte Métricas de Azure.

Almacén de consultas

La característica Almacén de consultas captura automáticamente el historial de consultas y estadísticas en tiempo de ejecución y lo conserva para que luego pueda revisarse. Segmenta los datos por tiempo para ver los patrones de uso temporales. Los datos de todos los usuarios, bases de datos y consultas se almacenan en una base de datos denominada azure_sys en la instancia de servidor flexible de Azure Database for PostgreSQL. Puede encontrar una guía paso a paso en Supervisión del rendimiento con el Almacén de consultas.

Use la instrucción siguiente para ver las cinco primeras instrucciones SQL que consumen E/S:

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

La extensión pg_stat_statements

La extensión pg_stat_statements ayuda a identificar consultas que consumen E/S en el servidor.

Use la instrucción siguiente para ver las cinco primeras instrucciones SQL que consumen E/S:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

Nota

Al usar el almacén de consultas o pg_stat_statements para que se rellenen las columnas blk_read_time y blk_write_time, debe habilitar el parámetro de servidor track_io_timing. Para más información sobre track_io_timing, consulte Parámetros de servidor.

Identificación de las causas principales

Si los niveles de consumo de E/S son altos en general, estas podrían ser las causas principales:

Transacciones de ejecución prolongada

Las transacciones de larga duración pueden consumir E/S, lo que puede generar un uso alto de E/S.

La consulta siguiente ayuda a identificar las conexiones que se ejecutan durante más tiempo:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Programación de puntos de control

El uso elevado de E/S también se puede observar en escenarios en los que con frecuencia hay un punto de control. Una manera de identificar esto es comprobando el archivo de registro del servidor flexible de Azure Database for PostgreSQL para ver el texto de registro siguiente: "LOG: los puntos de comprobación se producen con demasiada frecuencia."

También puede investigarlo mediante un enfoque en el que se guardan instantáneas periódicas de pg_stat_bgwriter con una marca de tiempo. Con las instantáneas guardadas, se puede calcular el intervalo de punto de control, el número de puntos de control solicitados y el número de puntos de control programados.

Proceso de demonio de vaciado automático disruptivo

Ejecute la consulta siguiente para supervisar el vaciado automático:

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

La consulta se usa para comprobar la frecuencia con la que se vacían las tablas en la tabla de datos.

  • last_autovacuum: fecha y hora en que se ejecutó el último vaciado automático en la tabla.
  • autovacuum_count: número de veces que se vació la tabla.
  • autoanalyze_count: número de veces que se analizó la tabla.

Resolución del uso elevado de E/S

Para resolver un uso elevado de E/S, puede usar cualquiera de los tres métodos siguientes.

El comando EXPLAIN ANALYZE

Después de identificar la consulta que consume E/S elevada, use EXPLAIN ANALYZE para investigar aún más la consulta y optimizarla. Para más información sobre el comando EXPLAIN ANALYZE, revise el plan de EXPLAIN.

Terminación de las transacciones de larga duración

Como opción, podría considerar la posibilidad de terminar una transacción de larga duración.

Para finalizar un identificador de proceso (PID) de la sesión, debe usar la consulta siguiente para detectarlo:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

También puede filtrar por otras propiedades, como usename (nombre de usuario) o datname (nombre de base de datos), etc.

Una vez que tenga el PID de la sesión, puede usar la consulta siguiente para finalizarlo:

SELECT pg_terminate_backend(pid);

Ajuste de los parámetros del servidor

Si observa que el punto de control se está produciendo con demasiada frecuencia, aumente el parámetro del servidor de max_wal_size hasta que la mayoría de los puntos de control estén controlados por el tiempo, en lugar de solicitarlos. En última instancia, el 90 % o más deben basarse en el tiempo, y el intervalo entre dos puntos de control debe aproximarse al valor checkpoint_timeout establecido en el servidor.

  • max_wal_size: las horas punta del horario comercial es un buen momento para llegar al valor max_wal_size. Para llegar a un valor, haga lo siguiente:

    1. Ejecute la siguiente consulta para obtener el LSN de WAL actual y anote el resultado:

      select pg_current_wal_lsn();

    2. Espere el número de segundos que indica checkpoint_timeout. Ejecute la siguiente consulta para obtener el LSN de WAL actual y anote el resultado:

      select pg_current_wal_lsn();

    3. Ejecute la consulta siguiente, que usa los dos resultados, para comprobar la diferencia, en gigabytes (GB):

      select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;

  • checkpoint_completion_target: un procedimiento recomendado sería establecer el valor en 0,9. Por ejemplo, un 0,9 para un valor checkpoint_timeout de 5 minutos indica que el objetivo para completar un punto de control es de 270 segundos [0,9*300 s]. Un valor de 0,9 proporciona una carga de E/S bastante coherente. Un valor agresivo de checkpoint_completion_target podría generar un aumento de la carga de E/S en el servidor.

  • checkpoint_timeout: puede aumentar el valor checkpoint_timeout con respecto al predeterminado establecido en el servidor. Al aumentar el valor, tenga en cuenta que también aumentaría el tiempo de recuperación tras el bloqueo.

Ajuste del vaciado automático para reducir las interrupciones

Para más información sobre la supervisión y el ajuste en escenarios en los que el vaciado automático resulte demasiado disruptivo, consulte Ajuste del vaciado automático.

Aumento del almacenamiento

Aumentar el almacenamiento ayuda cuando se agregan más IOPS al servidor. Para más información sobre el almacenamiento y el número de IOPS asociado, consulte Opciones de proceso y almacenamiento.

Contenido relacionado