Partager via

Résoudre les problèmes d’utilisation élevée des IOPS dans un serveur flexible Azure Database pour PostgreSQL

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article vous montre comment identifier rapidement la cause racine de l’utilisation élevée d’opérations d’E/S par seconde (IOPS) et les actions correctives pour contrôler l’utilisation d’opérations d’E/S par seconde (IOPS) lors de l’utilisation du serveur flexible Azure Database pour PostgreSQL.

Dans cet article, vous apprendrez comment :

  • Utiliser des guides de résolution des problèmes permettant d’identifier les causes racines et d’obtenir des recommandations afin de les atténuer.
  • Utiliser des outils permettant d’identifier une utilisation élevée d’opérations d’E/S par seconde, comme les indicateurs de performance Azure, le Magasin des requêtes et pg_stat_statements.
  • Identifier les causes racines, telles que les requêtes de longue durée, le minutage des points de contrôle, le processus de démon de nettoyage automatique disruptif et l’utilisation élevée du stockage.
  • Résoudre une utilisation élevée d’E/S en utilisant Explain Analyze, optimiser les paramètres serveur liés aux points de contrôle et paramétrer le démon de nettoyage automatique.

Guides de résolution des problèmes

À l’aide des guides de résolution des problèmes de fonctionnalités, disponibles sur le portail du serveur flexible Azure Database pour PostgreSQL, il est possible de trouver la cause racine probable et les recommandations pour atténuer le scénario d’utilisation élevée des IOPS. Pour savoir comment configurer les guides de résolution des problèmes, consultez Configurer des guides de résolution des problèmes.

Outils permettant d’identifier une utilisation élevée d’E/S

Nous vous recommandons les outils suivants pour identifier une utilisation élevée d’E/S.

Indicateurs de performance Azure

Les indicateurs de performance Azure constituent un bon point de départ pour vérifier l’utilisation d’E/S pour la date et la période définies. Les métriques fournissent des informations sur la durée pendant laquelle l’utilisation d’E/S est élevée. Comparez les graphiques d’opérations d’E/S par seconde d’écriture et de lecture ainsi que ceux de débit de lecture et de débit d’écriture pour déterminer les heures où la charge de travail a provoqué une utilisation élevée d’E/S. Pour une surveillance proactive, vous pouvez configurer des alertes sur les indicateurs de performance. Pour obtenir des instructions pas à pas, consultez Métriques Azure.

Magasin des requêtes

La fonctionnalité Magasin des requêtes capture automatiquement l’historique des requêtes et les statistiques d’exécution, et les garde pour que vous les évaluiez. Elle découpe les données par durée pour distinguer des modèles d’utilisation temporels. Les données de l’ensemble des utilisateurs, des bases de données et des requêtes sont stockées dans une base de données nommée azure_sys dans l’instance du serveur flexible Azure Database pour PostgreSQL. Pour obtenir des instructions pas à pas, consultez Surveiller les performances avec le Magasin des requêtes.

Utilisez l’instruction suivante pour voir les cinq premières instructions SQL qui consomment des 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;

Extension pg_stat_statements

L’extension pg_stat_statements permet d’identifier les requêtes qui consomment des E/S sur le serveur.

Utilisez l’instruction suivante pour voir les cinq premières instructions SQL qui consomment des E/S :

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

Remarque

Lorsque vous utilisez le magasin de requêtes ou pg_stat_statements pour remplir les colonnes blk_read_time et blk_write_time, vous devez activer le paramètre de serveur track_io_timing. Pour plus d’informations sur track_io_timing, consultez Paramètres de serveur.

Identifier les causes racines

Si les niveaux de consommation d’E/S sont généralement élevés, les causes racines peuvent être les suivantes :

Transactions de longue durée

Les transactions de longue durée peuvent consommer des E/S, ce qui peut entraîner une utilisation élevée d’E/S.

La requête suivante permet d’identifier les connexions actives depuis le plus longtemps :

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;

Minutages des points de contrôle

Une utilisation élevée d’E/S peut également être observée dans les scénarios où un point de contrôle est activé trop fréquemment. Un moyen d’identifier ce problème consiste à rechercher le texte de journal suivant dans le fichier journal du serveur flexible Azure Database pour PostgreSQL : « LOG: checkpoints are occurring too frequently ».

Vous pouvez également investiguer avec une approche consistant à enregistrer des captures instantanées régulières de pg_stat_bgwriter avec une date et une heure précises. À l’aide des captures instantanées enregistrées, vous pouvez calculer l’intervalle moyen des points de contrôle, le nombre de points de contrôle demandés et le nombre de points de contrôle planifiés.

Interruption de service du processus de démon de nettoyage automatique

Exécutez la requête suivante pour surveiller le nettoyage automatique :

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 requête est utilisée pour vérifier la fréquence à laquelle les tables de la base de données sont nettoyées.

  • last_autovacuum : date et heure auxquelles le dernier nettoyage automatique a été exécuté sur la table.
  • autovacuum_count : nombre de fois où la table a été nettoyée.
  • autoanalyze_count : nombre de fois où la table a été analysée.

Résoudre les problèmes d’utilisation élevée d’E/S

Pour résoudre une utilisation élevée des E/S, vous pouvez utiliser l’une des trois méthodes suivantes.

La commande EXPLAIN ANALYZE

Une fois que vous identifiez la requête qui consomme beaucoup d’E/S, utilisez EXPLAIN ANALYZE pour investiguer davantage la requête et l’ajuster. Pour plus d’informations sur la commande EXPLAIN ANALYZE, passez en revue le plan EXPLAIN.

Mettre fin aux transactions de longue durée

Vous pouvez envisager de tuer une transaction de longue durée le cas échéant.

Pour mettre fin au PID (ID de processus) d’une session, vous devez détecter le PID avec la requête suivante :

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;

Vous pouvez également filtrer en fonction d’autres propriétés comme usename (nom d’utilisateur) ou datname (nom de la base de données).

Une fois que vous disposez du PID de la session, vous pouvez y mettre fin à l’aide de la requête suivante :

SELECT pg_terminate_backend(pid);

Optimiser les paramètres de serveur

Si vous observez que le point de contrôle est activé trop fréquemment, augmentez le paramètre de serveur max_wal_size jusqu’à ce que la plupart des points de contrôle soient basés sur le temps, et non sur les requêtes. Au moins 90 % des points de contrôle doivent finir par être basés sur le temps, et l’intervalle entre deux points de contrôle doit se rapprocher de la valeur checkpoint_timeout définie sur le serveur.

  • max_wal_size : les heures de pointe constituent un bon moment pour arriver à la valeur max_wal_size. Pour atteindre une valeur, procédez comme suit :

    1. Exécutez la requête suivante pour obtenir le numéro séquentiel dans le journal WAL actuel, puis notez le résultat :

      select pg_current_wal_lsn();

    2. Attendez pendant checkpoint_timeout secondes. Exécutez la requête suivante pour obtenir le numéro séquentiel dans le journal WAL actuel, puis notez le résultat :

      select pg_current_wal_lsn();

    3. Exécutez la requête suivante, qui utilise les deux résultats, pour vérifier la différence, en gigaoctets (Go) :

      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 : une bonne pratique consisterait à définir la valeur sur 0,9. Par exemple, une valeur de 0,9 pour un checkpoint_timeout de 5 minutes indique que la cible pour effectuer un point de contrôle est de 270 secondes [0,9*300 secondes]. La valeur 0,9 fournit une charge d’E/S assez régulière. Une valeur agressive de checkpoint_completion_target peut entraîner une charge d’E/S accrue sur le serveur.

  • checkpoint_timeout : vous pouvez augmenter la valeur checkpoint_timeout à partir de la valeur par défaut définie sur le serveur. Lorsque vous augmentez la valeur, tenez compte du fait que l’augmentation de la valeur entraîne aussi une augmentation du temps de récupération en cas d’incident.

Optimiser le nettoyage automatique pour réduire les interruptions

Pour plus d’informations sur la surveillance et l’optimisation dans les scénarios où le nettoyage automatique provoque trop d’interruptions, consultez Réglage du nettoyage automatique.

Augmenter le stockage

L’augmentation du stockage est utile lorsque vous ajoutez davantage d’opérations d’E/S par seconde au serveur. Pour plus d’informations sur le stockage et les opérations d’E/S par seconde associées, consultez Options de calcul et de stockage.

Contenu connexe