Modifier votre configuration Databases for PostgreSQL

IBM Cloud® Databases for PostgreSQL vous permet de modifier certains paramètres de configuration d' PostgreSQL afin d'adapter vos bases de données PostgreSQL à votre cas d'utilisation. Pour apporter des modifications permanentes à la configuration de la base de données, utilisez le plug-in CLI ou l'API d' Cloud Databases afin d'enregistrer les modifications dans le fichier de configuration de votre déploiement.

La configuration est définie dans un schéma. Pour effectuer une modification, vous envoyez un objet JSON avec les paramètres et leurs nouvelles valeurs à l'API ou à l'interface de ligne de commande. Par exemple, pour définir le max_connections paramètre sur 150, vous devez fournir :

{"configuration":{"max_connections":150}}

à l'interface CLI ou à l'API.

Pour plus d'informations, voir Gestion des connexions PostgreSQL.

Utilisation de l'interface de ligne de commande avec Databases for PostgreSQL

Vous pouvez vérifier la configuration par défaut de votre déploiement à l'aide de la commande deployment-configuration-schema. La sortie de la deployment-configuration-schema commande n'affiche que la configuration par défaut, même après avoir modifié votre configuration. Pour afficher les modifications spécifiques à la base de données, interrogez directement la base de données.

ibmcloud cdb deployment-configuration-schema <INSTANCE_NAME_OR_CRN>

De même, modifiez votre configuration à l'aide de la commande deployment-configuration.

ibmcloud cdb deployment-configuration <INSTANCE_NAME_OR_CRN> [@JSON_FILE | JSON_STRING]

La commande lit les modifications que vous souhaitez effectuer à partir de l'objet JSON ou d'un fichier. Pour plus d'informations, voir la page de référence.

Utilisation de l'API avec IBM Cloud® Databases for PostgreSQL

Les deux noeuds finaux de configuration de déploiement permettent d'afficher le schéma de configuration et de modifier la configuration. Pour afficher le schéma de configuration, envoyez une demande GET à /deployments/{id}/configuration/schema.

Pour modifier la configuration, envoyez les paramètres que vous souhaitez modifier sous la forme d'un objet JSON dans le corps d'une demande PATCH vers /deployments/{id}/configuration.

Pour plus d'informations, consultez la référence API.

Paramètres de configuration disponibles IBM Cloud® Databases for PostgreSQL

Cette section fournit des informations sur les paramètres de configuration disponibles pour l' IBM Cloud Databases for PostgreSQL. Pour suggérer un paramètre de configuration qui ne figure pas ici comme amélioration du produit, soumettez votre idée sur le portail d'idées d' IBM. Si vous préférez, vous pouvez limiter votre affichage aux améliorations d' IBM Cloud s uniquement sur IBM Cloud Ideas.

IBM Cloud® Databases for PostgreSQL paramètres de fuseau horaire

Le fuseau horaire des déploiements IBM Cloud® Databases for PostgreSQL est toujours UTC (Coordinated Universal Time). Ce paramètre n'est pas configurable par les clients.

IBM Cloud® Databases for PostgreSQL paramètres de mémoire

shared_buffers

  • Valeur par défaut - 32000 (nombre de mémoires tampon de 8 kibioctets, ou environ 262 Mo)
  • Valeur maximale recommandée : 25 % de la mémoire RAM disponible
  • Redémarre la base de données ? - Oui

L'allocation de mémoire recommandée pour shared_buffers est 25% de la mémoire RAM du déploiement. Une shared_buffers valeur plus élevée peut entraîner des problèmes de mémoire qui provoquent le plantage de la base de données et peut réduire les performances de votre base de données, car les données sont très probablement déjà mises en mémoire tampon par le système d'exploitation. Si vous définissez shared_buffers sur une valeur égale, proche ou supérieure à la quantité de mémoire allouée, la base de données ne démarre pas. Le paramètre indique le nombre de tampons de mémoire partagée de 8 kibioctets.

Par exemple, 1 Go d'espace shared_buffers correspond à 1048576 KiB, et (1048576 KiB / 8 KiB) représente 131072 tampons. Votre déploiement peut utiliser la mémoire RAM supplémentaire pour la mise en cache et les performances, même sans l'allouer à shared_buffers. Il n'est pas nécessaire de configurer la base de données pour qu'elle utilise l'ensemble de la mémoire RAM allouée pour que votre déploiement l'utilise.

Concernant les charges de travail existantes, ou la mise à l'échelle de la mémoire RAM, l'augmentation de la mémoire dans les mémoires tampon partagées peut ne pas être la meilleure solution. A la place, effectuez le suivi de vos taux de réussite en cache de table et d'index. Si les taux de réussite du cache sont supérieurs à 90 %, laissez le système d'exploitation utiliser la mémoire dans d'autres domaines au lieu d'augmenter shared_buffers.

Vous pouvez utiliser ces requêtes en tant qu'utilisateur admin ou tout utilisateur disposant du rôle pg_monitor pour effectuer le suivi des taux de réussite en cache :

Tableaux

SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as table_hit_ratio
FROM
  pg_statio_user_tables;

Index

SELECT
  sum(idx_blks_read) as idx_read,
  sum(idx_blks_hit)  as idx_hit,
  (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as index_hit_ratio
FROM
pg_statio_user_indexes;

La valeur work_mem est automatiquement ajustée en relation avec les valeurs de configuration shared_buffer et max_connection.

IBM Cloud® Databases for PostgreSQL paramètres généraux

max_connections

max_locks_per_transaction

  • Valeur par défaut-64
  • Options - Valeur minimale de 10
  • Redémarre la base de données ? - OUI

max_prepared_transactions

  • Valeur par défaut - 50
  • Redémarre la base de données ? - OUI
  • Remarques - La valeur 0 désactive l'utilisation des transactions préparées et est recommandée à moins que vous n'ayez besoin de les utiliser.

synchronous_commit

  • Valeur par défaut - local
  • Redémarrage de base de données - Non
  • Options - local, onou off
  • Remarque : le paramètre synchronous_commit permet d'augmenter le taux de validation des transactions au détriment d'une perte de transactions validées en cas d'arrêt incorrect. Lorsque synchronous_commit est défini sur on, une transaction est validée uniquement lorsqu'elle est écrite sur le principal et au moins une réplique. Par conséquent, le paramètre on n'est disponible que sur les formations qui ont été mises à l'échelle horizontale pour au moins trois membres. Avant d'effectuer cette modification, voir Haute disponibilité.

effective_io_concurrency

  • Valeur par défaut - 12
  • Redémarrage de base de données - Non
  • Remarques - Il est recommandé de conserver la valeur par défaut de ce paramètre. Augmentez-le uniquement si vous avez profilé des requêtes SQL et avez observé des analyses Bitmap Heap Scans inefficaces. Comme l'IOPS est lié à la taille du disque, il n'est pas non plus recommandé d'augmenter ce paramètre sur les disques de taille standard ou plus petite.

deadlock_timeout

  • Valeur par défaut - 10000
  • Redémarrage de base de données - Non
  • Options : La valeur minimale est 100
  • Remarques - Le nombre de millisecondes à attendre avant de rechercher un interblocage et de vérifier la durée d'attente du verrou est consigné. Journaux disponibles via l'intégration de la journalisation. Si la valeur de ce paramètre est trop basse, les performances sont dégradées.

log_connections

  • Valeur par défaut - off
  • Redémarrage de base de données - Non
  • Options - Valeurs de on ou off
  • Remarques - Définir cette valeur sur on rend les journaux détaillés. Elle affiche également les connexions de l'outil de surveillance, car elle extrait des métriques toutes les 60 secondes. Lorsque cette option est définie sur on, il est recommandé de définir application_name dans l'URI de connexion afin de conserver une vue d'ensemble dans les journaux, car les adresses IP affichées sont les adresses IP internes de Kubernetes. Vous trouverez plus de détails sur le réglage de l'URI de connexion dans la documentation PostgreSQL. Lorsque cette option est définie sur off, le comportement par défaut n'est pas modifié et aucune connexion n'est journalisée. Les journaux sont disponibles via l'intégration de la journalisation. Si on est défini, les journaux affichent des lignes similaires à cet exemple, où le nom de l'application est défini comme test-app :
2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

  • Valeur par défaut - off
  • Redémarrage de base de données - Non
  • Options - Valeurs de on ou off
  • Remarques - Définir cette valeur sur on rend les journaux détaillés. Il affichera également les déconnexions des outils de surveillance, car il extrait les métriques toutes les 60 secondes. Lorsque cette option est définie sur on, il est recommandé de définir application_name dans l'URI de connexion afin de conserver une vue d'ensemble dans les journaux, car les adresses IP affichées sont les adresses IP internes de Kubernetes. Vous trouverez plus de détails sur le réglage de l'URI de connexion dans la documentation PostgreSQL. Lorsque cette option est définie sur off, le comportement par défaut n'est pas modifié et aucune déconnexion n'est journalisée. Les journaux sont disponibles via l'intégration de la journalisation. Si on est défini, les journaux affichent des lignes similaires à cet exemple, où le nom de l'application est défini comme test-app :
2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638

log_min_duration_statement

  • Valeur par défaut - 100
  • Redémarrage de base de données - Non
  • Options : La valeur minimale est 100
  • Remarques - Les instructions dont la durée d'exécution est supérieure au nombre de millisecondes spécifié sont consignées.

tcp_keepalives_idle

  • Valeur par défaut - 111
  • Redémarrage de base de données - Non

tcp_keepalives_interval

  • Valeur par défaut - 15
  • Redémarrage de base de données - Non

tcp_keepalives_count

  • Valeur par défaut - 6
  • Redémarrage de base de données - Non

IBM Cloud® Databases for PostgreSQL Paramètres WAL

archive_timeout

  • Valeur par défaut - 1800
  • Redémarrage de base de données - Non
  • Options - La valeur minimale est 300
  • Remarques - Nombre de secondes à attendre avant de forcer un basculement vers le fichier WAL suivant. Si le nombre de secondes s'est écoulé et qu'il y a eu une activité dans la base de données, le serveur passe à un nouveau segment. Permet de limiter efficacement la durée pendant laquelle les données peuvent rester désarchivées.

Les trois paramètres suivants, wal_level, max_replication_slots et max_wal_senders permettent d'utiliser le plug-in de décodage logique wal2json. Si vous n'utilisez pas ce plug-in, conservez la valeur par défaut de ces paramètres.

wal_level

  • Valeur par défaut - replica
  • Redémarrage de base de données - Oui
  • Remarques - Contrôle le niveau WAL. Les valeurs autorisées sont replica ou logical. Définissez sur logical pour utiliser le décodage logique. Si vous n'utilisez pas le décodage logique et que vous spécifiez la valeur logical, la taille WAL augmente, ce qui présente plusieurs inconvénients et aucun avantage réel.

max_replication_slots

  • Valeur par défaut - 10
  • Redémarrage de base de données - Oui
  • Remarques - Nombre maximal d'emplacements de réplication définis simultanément. Le nombre minimal d'emplacements est 10 ; il s'agit également de la valeur par défaut. Vingt emplacements sont réservés à une utilisation interne par votre déploiement à des fins de haute disponibilité. Pour utiliser des emplacements, vous devez définir une valeur supérieure à 20 et avoir un emplacement par consommateur. Ajoutez un emplacement supplémentaire par rapport au minimum par consommateur attendu. L'utilisation de wal2json sans augmenter max_replication_slots peut avoir une incidence sur les répliques à haute disponibilité et accessibles en lecture seule. Si vous n'utilisez pas wal2json, laissez ce paramètre à sa valeur par défaut.

max_wal_senders

  • Valeur par défaut - 12
  • Redémarrage de base de données - Oui
  • Remarques - Nombre maximal de processus émetteur WAL qui s'exécutent simultanément. La valeur par défaut, et minimale, est 12. Un wal_sender par consommateur est requis. Vingt emplacements sont réservés à une utilisation interne par votre déploiement à des fins de haute disponibilité. Vous devez définir une valeur supérieure à 20 et il est recommandé d'ajouter un unité supplémentaire wal_sender au-delà du minimum par consommateur prévu. L'utilisation de wal2json sans augmenter max_wal_senders peut avoir une incidence sur les répliques à haute disponibilité et accessibles en lecture seule. Si vous n'utilisez pas wal2json, laissez ce paramètre à sa valeur par défaut.