Compartir a través de

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

SE APLICA A: Azure Database for PostgreSQL: 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 un uso elevado de entrada y salida (E/S), como métricas de Azure, 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 mediante Explain Analyze, ajuste los parámetros del 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. Cómo configurar las guías de solución de problemas para usarlas, siga guías de solución de problemas de configuración.

Herramientas para identificar un uso elevado de E/S

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

Métricas de Azure

Métricas de Azure es un buen punto de partida para comprobar el uso de E/S para una fecha y un período definidos. Las métricas dan información sobre el tiempo durante el cual la utilización de E/S es alta. Compare los gráficos de E/S de escritura, E/S de lectura, rendimiento de lectura y rendimiento de escritura para averiguar los tiempos en los que la carga de trabajo está causando 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 las conserva para su revisión. 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. Para obtener instrucciones paso a paso, consulte 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 larga duración

Las transacciones de larga duración pueden consumir E/S, lo que puede dar lugar a un uso elevado 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;

Intervalos 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 con qué frecuencia se vacían las tablas de la base 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 es cercano 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 valor de 0,9 para un checkpoint_timeout de 5 minutos indica que el destino para completar un punto de comprobación es de 270 segundos (0,9*300 segundos). Un valor de 0,9 proporciona una carga de E/S bastante coherente. Un valor agresivo de checkpoint_completion_target podría dar lugar a una mayor carga de E/S en el servidor.

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

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 obtener más información sobre el almacenamiento y las IOPS asociadas, consulte Opciones de proceso y almacenamiento.

Contenido relacionado