Partager via

Résoudre les problèmes liés à l’utilisation élevée d’IOPS pour Azure Database pour PostgreSQL – Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

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

Dans cet article, vous apprendrez comment :

  • À propos des guides de résolution des problèmes pour identifier et obtenir des recommandations afin d’atténuer les causes racines.
  • Utiliser des outils permettant d’identifier une utilisation élevée d’E/S par seconde, comme les métriques 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, la probable cause racine et les recommandations pour atténuer le scénario d’utilisation élevée des IOPS sont disponibles. 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.

Métriques Azure

Les métriques Azure constituent un bon point de départ pour vérifier l’utilisation d’E/S à 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’E/S par seconde d’écriture et de lecture, 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 métriques. 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 des statistiques d’exécution, et les garde pour que vous les consultiez. Il découpe les données par heure pour voir les modèles d’utilisation temporelle. Les données de l’ensemble des utilisateurs, bases de données et 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 conseils 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;

Notes

Lorsque vous utilisez le magasin de requêtes ou pg_stat_statements pour les colonnes blk_read_time et blk_write_time à remplir, 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 s’exécutant 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

Vous pouvez aussi avoir une utilisation élevée d’E/S dans les scénarios où un point de contrôle se produit trop fréquemment. Un moyen d’identifier ce problème consiste à rechercher dans le fichier journal le texte de journal Azure Database pour PostgreSQL suivant : « LOG: checkpoints are occurring too frequently » (les points de contrôle se produisent trop souvent).

Vous pouvez également investiguer avec une approche où des captures instantanées régulières de pg_stat_bgwriter avec un horodatage sont enregistrées. À 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.

Processus de démon de nettoyage automatique perturbant

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 se produit 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 des demandes. 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 augmente aussi le 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 est trop disruptif, consultez Réglage du nettoyage automatique.

Augmenter le stockage

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

Contenu connexe