Paramètres de serveur Azure Cosmos DB for PostgreSQL

Article
12/17/2023

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

Il existe différents paramètres de serveur qui affectent le comportement d’Azure Cosmos DB pour PostgreSQL, à la fois à partir de PostgreSQL standard et spécifiques à Azure Cosmos DB pour PostgreSQL. Ces paramètres peuvent être définis sur le portail Azure pour un cluster. Sous la catégorie Paramètres, choisissez les paramètres du Nœud worker ou du Nœud coordinateur. Ces pages vous permettent de définir des paramètres pour tous les nœuds Worker, ou uniquement pour le nœud coordinateur.

Paramètres Azure Cosmos DB for PostgreSQL

Remarque

Il se pourrait que des clusters exécutant des versions antérieures de l’extension Citus ne proposent pas tous les paramètres répertoriés ci-dessous.

Configuration générale

citus.use_secondary_nodes (énumération)

Définit la stratégie à utiliser lors du choix des nœuds pour les requêtes SELECT. S’il est défini sur « always », le planificateur interroge uniquement les nœuds marqués en tant que noderole « secondaires » dans pg_dist_node.

Les valeurs prises en charge pour cette énumération sont les suivantes :

jamais : (par défaut) toutes les lectures se produisent sur les nœuds principaux.
always : Les lectures sont exécutées sur les nœuds secondaires à la place et les commandes insert/update sont désactivées.

citus.cluster_name (texte)

Informe le responsable du nœud coordinateur du cluster qu’il coordonne. Une fois cluster_name défini, le planificateur interroge seulement les nœuds Worker dans ce cluster.

citus.enable_version_checks (booléen)

Mettre à niveau la version d’Azure Cosmos DB for PostgreSQL nécessite un redémarrage serveur (pour récupérer la nouvelle bibliothèque partagée), suivie de la commande ALTER EXTENSION UPDATE. L’échec de l’exécution des deux étapes peut entraîner des erreurs ou des blocages. Azure Cosmos DB for PostgreSQL valide donc la correspondance de la version du code et celle de l’extension, et retourne une erreur si elles ne correspondent pas.

Cette valeur est définie par défaut sur true et est effective sur le coordinateur. Dans de rares cas, les processus de mise à niveau complexes pourraient nécessiter l’affectation de la valeur false à ce paramètre, ce qui désactive la vérification.

citus.log_distributed_deadlock_detection (booléen)

Indique s’il faut enregistrer le traitement lié à la détection de blocage distribué dans le journal du serveur. La valeur par défaut est « False ».

citus.distributed_deadlock_detection_factor (virgule flottante)

Définit le délai d’attente avant de vérifier les blocages distribués. En particulier, le délai d’attente est cette valeur multipliée par le paramètre deadlock_timeout de PostgreSQL. La valeur par défaut est 2. Une valeur de -1 désactive la détection de blocage distribué.

citus.node_connection_timeout (entier)

Le GUC citus.node_connection_timeout définit la durée maximale (en millisecondes) d’attente de l’établissement de la connexion. Azure Cosmos DB for PostgreSQL génère une erreur si le délai d’attente s’écoule avant qu’au moins une connexion Worker soit établie. Ce GUC affecte les connexions entre le coordinateur et les workers, ainsi qu’entre les workers.

Par défaut : cinq secondes
Minimum : 10 millisecondes
Maximum : une heure

-- set to 30 seconds
ALTER DATABASE foo
SET citus.node_connection_timeout = 30000;

citus.log_remote_commands (booléen)

Journaliser toutes les commandes que le coordinateur envoie aux nœuds Worker. Exemple :

-- reveal the per-shard queries behind the scenes
SET citus.log_remote_commands TO on;

-- run a query on distributed table "github_users"
SELECT count(*) FROM github_users;

La sortie révèle plusieurs requêtes exécutées sur les Workers en raison de la requête count(*) unique sur le coordinateur.

NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102040 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102041 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE:  issuing SELECT count(*) AS count FROM public.github_events_102042 github_events WHERE true
DETAIL:  on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
... etc, one for each of the 32 shards

citus.show_shards_for_app_name_prefixes (text)

Par défaut, Azure Cosmos DB for PostgreSQL masque les partitions de la liste des tables que PostgreSQL donne aux clients SQL. Cela est dû au fait qu’il existe plusieurs partitions par table distribuée et que les partitions peuvent être détournées du client SQL.

Le GUC citus.show_shards_for_app_name_prefixes permet aux partitions d’être affichées pour les clients sélectionnés qui souhaitent les voir. Sa valeur par défaut est ».

-- show shards to psql only (hide in other clients, like pgAdmin)

SET citus.show_shards_for_app_name_prefixes TO 'psql';

-- also accepts a comma separated list

SET citus.show_shards_for_app_name_prefixes TO 'psql,pg_dump';

Le masquage de partitions peut être désactivé entièrement à l’aide de citus.override_table_visibility.

citus.override_table_visibility (booléen)

Détermine si citus.show_shards_for_app_name_prefixes est actif. La valeur par défaut est « true ». Lorsque la valeur est « false », les partitions sont visibles pour toutes les applications clientes.

citus.use_citus_managed_tables (booléen)

Autoriser les nouvelles tables locales à accéder aux requêtes sur les nœuds Worker. Ajoute toutes les tables nouvellement créées aux métadonnées Citus lorsqu’elles sont activées. La valeur par défaut est « false ».

citus.rebalancer_by_disk_size_base_cost (entier)

Avec la stratégie de rééquilibrage by_disk_size, chaque groupe de partitions voit ce coût en octets s’ajouter à celui de sa taille de disque réelle. Cette valeur est utilisée pour éviter de créer un mauvais équilibre lorsqu’il y a peu de données dans certaines des partitions. L’hypothèse est que même les partitions vides ont un certain coût, en raison du parallélisme et parce que les groupes de partitions vides sont susceptibles de croître à l’avenir.

La valeur par défaut est 100MB.

Statistiques sur les requêtes

citus.stat_statements_purge_interval (entier)

Définit la fréquence à laquelle le démon de maintenance supprime les enregistrements de citus_stat_statements qui n’ont pas de correspondance pas dans pg_stat_statements. Cette valeur de configuration définit l’intervalle de temps entre les suppressions, en secondes, avec une valeur par défaut de 10. La valeur 0 désactive les suppressions.

SET citus.stat_statements_purge_interval TO 5;

Ce paramètre est effectif sur le coordinateur et peut être modifié au moment de l’exécution.

citus.stat_statements_max (entier)

Nombre maximal de lignes à stocker dans citus_stat_statements. La valeur par défaut (50 000) peut être modifiée sur n’importe quelle valeur comprise dans la plage 1 000 et 10 000 000. Chaque ligne requiert 140 octets de stockage, donc si le paramètre stat_statements_max est défini sur la valeur maximale (10M), 1,4 Go de mémoire sera consommé.

La modification de ce GUC ne prend effet qu’à partir du redémarrage de PostgreSQL.

citus.stat_statements_track (énumération)

L’enregistrement des statistiques pour citus_stat_statements requiert des ressources processeur supplémentaires. Quand la base de données gère une charge importante, l’administrateur peut désactiver le suivi des instructions en définissant citus.stat_statements_track sur none.

all : (valeur par défaut) suit toutes les instructions.
none : désactiver le suivi.

citus.stat_tenants_untracked_sample_rate

Taux d’échantillonnage pour les nouveaux locataires dans citus_stat_tenants. Le taux peut être compris entre 0.0 et 1.0. La valeur par défaut 1.0 signifie que 100 % des requêtes de locataires non suivies sont échantillonnées. La définition d’une valeur inférieure signifie que les locataires déjà suivis ont des requêtes échantillonnées de 100 %, mais que les locataires actuellement non suivis ne sont échantillonnés qu’au taux fourni.

Chargement des données

citus.multi_shard_commit_protocol (énumération)

Définit le protocole de validation à utiliser lors de l’exécution d’une copie sur une table distribuée de hachage. À chaque sélection élective de partition individuelle, la commande COPY est effectuée dans un bloc de transaction pour garantir qu’aucune donnée n’est ingérée si une erreur se produit pendant la copie. Toutefois, il existe un cas de défaillance particulier dans lequel la commande COPY est réussie sur toutes les sélections électives, mais une défaillance (matérielle) se produit avant la validation de toutes les transactions. Ce paramètre peut être utilisé pour éviter la perte de données dans ce cas en choisissant entre les protocoles de validation suivants :

2pc : (par défaut) Les transactions dans lesquelles l’opération COPY est effectuée sur les placements de partitions sont d’abord préparées en utilisant un une validation en deux phases de PostgreSQL, puis elles sont validées. Les validations ayant échoué peuvent être récupérées ou annulées manuellement à l’aide de COMMIT PREPARED ou ROLLBACK PREPARED, respectivement. Lors de l’utilisation de 2pc, max_prepared_transactions doit être augmenté sur tous les Workers, généralement sur à la même valeur que max_connections.
1pc : Les transactions dans lesquelles la commande COPY est effectuée sur les sélections électives de partition sont validées en une seule fois. Les données peuvent être perdues si une validation échoue après la fin de la copie sur toutes les sélections électives (cas rare).

citus.shard_replication_factor (entier)

Définit le facteur de réplication pour partitions, c’est-à-dire le nombre de nœuds sur lesquels les partitions sont placées, et la valeur par défaut est 1. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur. La valeur idéale pour ce paramètre dépend de la taille du cluster et du taux d’échec du nœud. Par exemple, vous souhaitez augmenter ce facteur de réplication si vous exécutez des clusters de grande taille et observez les défaillances de nœuds plus fréquemment.

Configuration du planificateur

citus.local_table_join_policy (énumération)

Ce GUC détermine comment Azure Cosmos DB for PostgreSQL déplace les données lors de l’établissement d’une jointure entre des tables locales et distribuées. La personnalisation de la stratégie de jointure peut aider à réduire la quantité de données envoyées entre les nœuds Worker.

Si nécessaire, Azure Cosmos DB for PostgreSQL envoie les tables locales ou distribuées aux nœuds pour prendre en charge la jointure. La copie de données de table est appelée « conversion ». Si une table locale est convertie, elle est envoyée aux Workers qui ont besoin de ses données pour effectuer la jointure. Si une table distribuée est convertie, elle est collectée dans le coordinateur pour prendre en charge la jointure. Le planificateur Azure Cosmos DB for PostgreSQL envoie uniquement les lignes nécessaires effectuant une conversion.

Quatre modes permettent d’exprimer la préférence de conversion :

auto : (par défaut) Azure Cosmos DB for PostgreSQL convertit toutes les tables locales ou toutes les tables distribuées pour prendre en charge les jointures de tables locales et distribuées. Azure Cosmos DB pour PostgreSQL décide de convertir à l’aide d’une heuristique. Il convertit les tables distribuées si elles sont jointes à l’aide d’un filtre constant sur un index unique (par exemple, une clé primaire). La conversion garantit que moins de données sont déplacées entre les Workers.
jamais : Azure Cosmos DB for PostgreSQL n’autorise pas les jointures entre les tables locales et distribuées.
prefer-local : Azure Cosmos DB for PostgreSQL préfère convertir les tables locales pour prendre en charge les jointures de tables locales et distribuées.
prefer-distributed : Azure Cosmos DB for PostgreSQL préfère convertir les tables distribuées pour prendre en charge les jointures de tables locales et distribuées. Si les tables distribuées sont volumineuses, l’utilisation de cette option peut entraîner le déplacement d’un grand nombre de données entre les Workers.

Par exemple, supposons que citus_table est une table distribuée par la colonne x et que postgres_table est une table locale :

CREATE TABLE citus_table(x int primary key, y int);
SELECT create_distributed_table('citus_table', 'x');

CREATE TABLE postgres_table(x int, y int);

-- even though the join is on primary key, there isn't a constant filter
-- hence postgres_table will be sent to worker nodes to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x);

-- there is a constant filter on a primary key, hence the filtered row
-- from the distributed table will be pulled to coordinator to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;

SET citus.local_table_join_policy to 'prefer-distributed';
-- since we prefer distributed tables, citus_table will be pulled to coordinator
-- to support the join. Note that citus_table can be huge.
SELECT * FROM citus_table JOIN postgres_table USING (x);

SET citus.local_table_join_policy to 'prefer-local';
-- even though there is a constant filter on primary key for citus_table
-- postgres_table will be sent to necessary workers because we are using 'prefer-local'.
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;

citus.limit_clause_row_fetch_count (entier)

Définit le nombre de lignes à extraire par tâche pour l’optimisation de la clause LIMIT. Dans certains cas, certaines requêtes avec des clauses de limitation pourraient avoir besoin d’extraire toutes les lignes de chaque tâche pour générer des résultats. Dans ces cas-là, et lorsqu’une approximation produirait des résultats significatifs, cette valeur de configuration définit le nombre de lignes à extraire à partir de chaque partition. Les approximations de limites sont désactivées par défaut et ce paramètre est définit sur -1. Cette valeur peut être définie au moment de l’exécution et est effective sur le coordinateur.

citus.count_distinct_error_rate (virgule flottante)

Azure Cosmos DB for PostgreSQL peut calculer le nombre count(distinct) approximatif à l’aide de l’extension postgresql-hll. Cette entrée de configuration définit le taux d’erreur souhaité lors du calcul du count(distinct). 0,0, qui est la valeur par défaut, désactive les approximations pour count(distinct); et 1,0 ne fournit aucune garantie quant à l’exactitude des résultats. Nous vous recommandons de définir ce paramètre sur 0,005 pour obtenir de meilleurs résultats. Cette valeur peut être définie au moment de l’exécution et est effective sur le coordinateur.

citus.task_assignment_policy (énumération)

Notes

Ce paramètre GUC s’applique uniquement lorsque shard_replication_factor est supérieur à un, ou pour les requêtes sur reference_tables.

Définit la stratégie à utiliser lors de l’affectation de tâches aux workers. Le coordinateur affecte des tâches aux workers en fonction des emplacements de partition. Cette valeur de configuration spécifie la stratégie à utiliser lors de ces affectations. Actuellement, il existe trois stratégies d’attribution de tâches possibles qui peuvent être utilisées.

greedy : La stratégie greedy est la stratégie par défaut et vise à répartir uniformément les tâches entre les workers.
round-robin : La stratégie round-robin attribue des tâches aux workers dans un mode round robin alternant entre les différents réplicas. Cette stratégie permet une meilleure utilisation du cluster lorsque le nombre de partitions pour une table est faible par rapport au nombre de workers.
first-replica : la stratégie first-replica assigne des tâches en fonction de l’ordre d’insertion des placements (réplicas) pour les partitions. En d’autres termes, la requête de fragment pour une partition est assignée au worker qui a le premier réplica de cette partition. Cette méthode vous permet d’avoir des garanties fortes quant à quelles partitions seront utilisées sur quels nœuds (autrement dit, de plus fortes garanties de fichiers restant en mémoire).

Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.enable_non_colocated_router_query_pushdown (booléen)

Active le planificateur de routeurs pour les requêtes qui référencent des tables distribuées non colocalisées.

Le planificateur de routeurs est activé uniquement pour les requêtes qui référencent des tables distribuées colocalisées, car, dans le cas contraire, les partitions peuvent ne pas se trouver sur le même nœud. L’activation de cet indicateur permet d’optimiser les requêtes qui référencent ces tables, mais la requête pourrait ne pas fonctionner après le rééquilibrage des partitions ou la modification du nombre de partitions de ces tables.

Par défaut, il s’agit de off.

Transfert des données intermédiaires

citus.max_intermediate_result_size (entier)

Taille maximale, en Ko, des résultats intermédiaires pour les expressions de table commune qui ne peuvent pas être transférées vers les nœuds Worker pour exécution, et pour les sous-requêtes complexes. La valeur par défaut est 1 Go et la valeur -1 signifie aucune limite. Les requêtes qui dépassent la limite sont annulées et génèrent un message d’erreur.

DDL

citus.enable_schema_based_sharding

La définition du paramètre sur ON entraîne la distribution par défaut de tous les schémas créés. Les schémas distribués sont automatiquement associés à des groupes de colocation individuels, de sorte que les tables créées dans ces schémas sont converties en tables distribuées colocalisées sans clé de partition. Ce paramètre peut être modifié pour des sessions individuelles.

Pour obtenir un exemple d’utilisation de ce GUC, consultez Comment concevoir pour les microservices.

Configuration de l’exécuteur

Général

citus.all_modifications_commutative

Azure Cosmos DB for PostgreSQL applique les règles de commutativité et acquiert les verrous appropriés pour les opérations de modification afin de garantir l’exactitude du comportement. Par exemple, il suppose qu’une instruction INSERT est commutative avec une autre instruction INSERT, mais pas avec une instruction UPDATE ou DELETE. De même, il suppose qu’une instruction UPDATE ou DELETE ne commute pas avec une autre instruction UPDATE ou DELETE. Cette précaution signifie que les mises à jour et les suppressions nécessitent que Azure Cosmos DB for PostgreSQL acquiert des verrous plus forts.

Si vous avez des instructions UPDATE qui sont commutatives avec vos INSERT ou d’autres UPDATE, vous pouvez assouplir ces hypothèses de commutativité en affectant à ce paramètre la valeur true. Lorsque ce paramètre est défini sur true, toutes les commandes sont considérées comme commutatives et revendiquent un verrou partagé, ce qui peut améliorer le débit global. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.remote_task_check_interval (entier)

Définit la fréquence à laquelle Azure Cosmos DB for PostgreSQL vérifie les états des tâches gérés par l’exécuteur de suivi de tâches. La valeur par défaut est 10 ms. Le coordinateur attribue des tâches aux Workers, puis vérifie régulièrement auprès de ceux-ci la progression de chaque tâche. Cette valeur de configuration définit l’intervalle de temps entre deux contrôles. Ce paramètre est effectif sur le coordinateur et peut être défini au moment de l’exécution.

citus.task_executor_type (énumération)

Azure Cosmos DB for PostgreSQL a trois types d’exécuteur pour l’exécution de requêtes SELECT distribuées. L’exécuteur souhaité peut être sélectionné en définissant ce paramètre de configuration. Les valeurs acceptables pour ce paramètre sont :

adaptive : Valeur par défaut. Elle est optimale pour les réponses rapides aux requêtes qui impliquent des agrégations et des jointures en colocation s’étendant sur plusieurs partitions.
task-tracker : L’exécuteur de suivi des tâches est adapté aux requêtes durables et complexes qui nécessitent une réutilisation aléatoire des données sur les nœuds Worker et une gestion efficace des ressources.
real-time : (déconseillé) A un objectif similaire à celui de l’exécuteur adaptatif, mais il est moins flexible et peut entraîner une plus grande sollicitation des connexions sur les nœuds Worker.

Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.multi_task_query_log_level (énumération) {#multi_task_logging}

Définit un niveau de journal pour toute requête qui génère plus d’une tâche (c’est-à-dire, qui atteint plusieurs partitions). La journalisation est utile lors d’une migration d’applications multilocataire, car vous pouvez choisir d’émettre des erreurs ou des avertissements pour de telles requêtes, de les trouver et d’y ajouter un filtre id_locataire. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur. La valeur par défaut de ce paramètre est « off ».

Les valeurs prises en charge pour cette enum sont les suivantes :

off : Désactivez la journalisation des requêtes qui génèrent plusieurs tâches (autrement dit, s’étendent sur plusieurs partitions)
debug : Journalise l’instruction au niveau de gravité DEBUG.
log : Journalise l’instruction au niveau de gravité LOG. La ligne de journal comprend la requête SQL qui a été exécutée.
notice : Journalise l’instruction au niveau de gravité NOTICE.
warning : Journalise l’instruction au niveau de gravité WARNING.
error : Journalise l’instruction au niveau de gravité ERROR.

Il peut être utile d’utiliser error lors des tests de développement, ainsi qu’un niveau de journalisation plus bas comme log au cours du déploiement en production proprement dit. Si vous choisissez log , les requêtes multitâches apparaitront dans les journaux de base de données avec la requête elle-même, figurant après « STATEMENT ».

LOG:  multi-task query about to be executed
HINT:  Queries are split to multiple tasks if they have to be split into several queries on the workers.
STATEMENT:  select * from foo;

citus.propagate_set_commands (énumération)

Détermine les commandes SET qui sont propagées du coordinateur vers les Workers. La valeur par défaut de ce paramètre est « none ».

Les valeurs prises en charge sont les suivantes :

none : aucune commande SET n’est propagée.
local : seules les commandes SET LOCAL sont propagées.

citus.create_object_propagation (enum)

Contrôle le comportement des instructions CREATE dans les transactions pour les objets pris en charge.

Lorsque des objets sont créés dans un bloc de transaction multi-instruction, Azure Cosmos DB for PostgreSQL bascule le mode séquentiel pour garantir que les objets créés sont visibles par des instructions ultérieures sur des partitions. Toutefois, le commutateur en mode séquentiel n’est pas toujours souhaitable. En remplaçant ce comportement, l’utilisateur peut échanger les performances pour une cohérence transactionnelle complète lors de la création d’objets.

La valeur par défaut de ce paramètre est « immediate ».

Les valeurs prises en charge sont les suivantes :

immédiat : déclenche une erreur dans les transactions où des opérations parallèles telles que create_distributed_table se produisent avant une tentative de TYPE CREATE.
automatique : différer la création de types lors du partage d’une transaction avec une opération parallèle sur des tables distribuées. Il pourrait y avoir des incohérences entre les objets de base de données qui existent sur différents nœuds.
différé : revenez au comportement antérieur à 11.0, ce qui est comme automatique, mais avec d’autres cas de coin subtils. Nous recommandons le paramètre automatique sur différé, sauf si vous avez besoin d’une compatibilité descendante vraie.

Pour obtenir un exemple de ce GUC en action, consultez la propagation de type.

citus.enable_repartition_joins (booléen)

En règle générale, la tentative d’exécution de jointures de répartition avec l’exécuteur adaptatif échoue avec un message d’erreur. Toutefois, l’affectation de la valeur true à citus.enable_repartition_joins permet à Azure Cosmos DB for PostgreSQL de basculer temporairement dans l’exécuteur de suivi des tâches pour effectuer la jointure. La valeur par défaut est false.

citus.enable_repartitioned_insert_select (booléen)

Par défaut, une instruction INSERT INTO... L’instruction SELECT qui ne peut pas être transférée tente de repartitionner les lignes à partir de l’instruction SELECT et de les transférer entre les Workers pour insertion. Toutefois, si la table cible présente trop de partitions, il est probable que le repartitionnement ne fonctionnera pas correctement. La surcharge liée au traitement des intervalles de partition en vue de déterminer les modalités de partitionnement des résultats est trop importante. Le repartitionnement peut être désactivé manuellement en définissant citus.enable_repartitioned_insert_select sur false.

citus.enable_binary_protocol (booléen)

Si ce paramètre a la valeur true, le nœud coordinateur utilise le format de sérialisation binaire PostgreSQL (le cas échéant) pour transférer des données avec les Workers. Certains types de colonnes ne prennent pas en charge la sérialisation binaire.

L’activation de ce paramètre est surtout utile lorsque les Workers doivent retourner de grandes quantités de données. Par exemple, lorsque de nombreuses lignes sont demandées, les lignes présentent de nombreuses colonnes ou utilisent des types larges tels que hll à partir de l’extension postgresql-hll.

La valeur par défaut est true. Lorsque la valeur est définie sur false, tous les résultats sont encodés et transférés au format texte.

citus.max_adaptive_executor_pool_size (entier)

Max_adaptive_executor_pool_size limite les connexions de travail à partir de la session active. Ce GUC est utile pour :

empêcher un seul back-end d’obtenir toutes les ressources Worker ;
gérer les priorités : désigner les sessions à faible priorité présentant une valeur max_adaptive_executor_pool_size faible et les sessions à priorité élevée présentant des valeurs plus élevées.

La valeur par défaut est 16.

citus.executor_slow_start_interval (entier)

Délai d’attente en millisecondes entre les connexions ouvertes sur le même nœud Worker.

Lorsque les tâches individuelles d’une requête sur plusieurs partitions prennent peu de temps, elles peuvent souvent se terminer sur une connexion unique (souvent déjà mise en cache). Pour éviter d’ouvrir de manière redondante d’autres connexions, l’exécuteur attend entre les tentatives de connexion le nombre de millisecondes configuré. À la fin de l’intervalle, il augmente le nombre de connexions qu’il est autorisé à ouvrir la prochaine fois.

Pour les requêtes longues (qui prennent >500 ms), le démarrage lent peut augmenter la latence, mais pour les requêtes courtes, le démarrage est plus rapide. La valeur par défaut est de 10 ms.

citus.max_cached_conns_per_worker (entier)

Chaque back-end ouvre des connexions aux Workers pour interroger les partitions. À la fin de la transaction, le nombre configuré de connexions est maintenu ouvert pour accélérer les commandes suivantes. L’augmentation de cette valeur réduit la latence des requêtes multipartitions, mais augmente la surcharge sur les Workers.

La valeur par défaut est 1. Une valeur plus élevée (par exemple, 2) peut être utile pour les clusters qui utilisent un petit nombre de sessions simultanées, mais il n’est pas judicieux d’aller plus loin (par exemple, 16 est trop élevé).

citus.force_max_query_parallelization (booléen)

Simule l’exécuteur en temps réel abandonné et désormais inexistant. Ce paramètre permet d’ouvrir le plus grand nombre de connexions possibles pour optimiser la parallélisation des requêtes.

Lorsque cette GUC est activée, Azure Cosmos DB for PostgreSQL force l’exécuteur adaptatif à utiliser autant de connexions que possible lors de l’exécution d’une requête distribuée parallèle. Si ce paramètre n’est pas activé, l’exécuteur peut choisir d’utiliser moins de connexions pour optimiser le débit global d’exécution des requêtes. En interne, la définition de ce paramètre sur true entraîne l’utilisation d’une connexion par tâche.

Ce paramètre est utile dans une transaction dont la première requête est légère et nécessite peu de connexions, tandis qu’une requête ultérieure pourrait bénéficier de connexions supplémentaires. Azure Cosmos DB for PostgreSQL détermine le nombre de connexions à utiliser dans une transaction basée sur la première instruction, ce qui peut limiter les autres requêtes, sauf si nous utilisons le GUC pour fournir un conseil.

BEGIN;
-- add this hint
SET citus.force_max_query_parallelization TO ON;

-- a lightweight query that doesn't require many connections
SELECT count(*) FROM table WHERE filter = x;

-- a query that benefits from more connections, and can obtain
-- them since we forced max parallelization above
SELECT ... very .. complex .. SQL;
COMMIT;

La valeur par défaut est false.

Configuration de l’exécuteur du suivi des tâches

citus.task_tracker_delay (entier)

Ce paramètre définit la durée de veille du suivi des tâches entre les phases de gestion des tâches et la valeur par défaut de 200 ms. Le processus du suivi des tâches se réveille régulièrement, passe en revue toutes les tâches qui lui sont affectées et planifie et exécute ces tâches. Ensuite, le suivi des tâches se met en veille pendant une période de temps avant de parcourir ces tâches à nouveau. Cette valeur de configuration détermine la durée de cette période de sommeil. Ce paramètre est effectif sur les Workers et doit être modifié dans le fichier PostgreSQL. conf. Après avoir modifié le fichier de configuration, les utilisateurs peuvent envoyer un signal SIGHUP ou redémarrer le serveur pour que cette modification prenne effet.

Ce paramètre peut être réduit pour diminuer le délai dû à l’exécuteur du suivi des tâches en réduisant l’intervalle de temps entre les phases de gestion. La diminution du délai est utile dans les cas où les requêtes de partition sont courtes et, par conséquent, mettent régulièrement à jour leur état.

citus.max_assign_task_batch_size (entier)

L’exécuteur du suivi des tâches sur le coordinateur assigne de façon synchrone des tâches par lots au démon sur les Workers. Ce paramètre définit le nombre maximal de tâches à assigner dans un lot unique. Le choix d’une taille de lot plus importante permet une attribution plus rapide des tâches. Toutefois, si le nombre de Workers est élevé, l’obtention de tâches par tous les Workers peut prendre plus de temps. Ce paramètre peut être défini au moment de l’exécution et est effectif sur le coordinateur.

citus.max_running_tasks_per_node (entier)

Le processus du suivi des tâches planifie et exécute les tâches qui lui sont assignées, le cas échéant. Cette valeur de configuration définit le nombre maximal de tâches à exécuter simultanément sur un nœud à tout moment donné et la valeur par défaut est 8.

La limite vous permet de ne pas avoir de nombreuses tâches impactant le disque en même temps et d’éviter la contention des E/S disque. Si vos requêtes sont traitées à partir de la mémoire ou de disques SSD, vous pouvez augmenter max_running_tasks_per_node sans grand problème.

citus.partition_buffer_size (entier)

Définit la taille de la mémoire tampon à utiliser pour les opérations de partition et la valeur par défaut est de 8 Mo. Azure Cosmos DB for PostgreSQL permet de repartitionner les données de table en plusieurs fichiers lorsque deux tables volumineuses sont jointes. Une fois cette mémoire tampon remplie, les données de nouveau partitionnées sont vidées dans des fichiers sur le disque. Cette entrée de configuration peut être définie au moment de l’exécution et est effective sur les Workers.

Sortie explain

citus.explain_all_tasks (booléen)

Par défaut, Azure Cosmos DB for PostgreSQL affiche le résultat d’une tâche arbitraire unique lors de l’exécution d’EXPLAIN sur une requête distribuée. Dans la plupart des cas, le résultat « explain » sera similaire entre les tâches. Il arrive que certaines tâches soient planifiées différemment ou aient des durées d’exécution bien supérieures. Dans ces cas, il peut être utile d’activer ce paramètre, après quoi le résultat EXPLAIN inclura toutes les tâches. L’explication de toutes les tâches pourrait rallonger le délai pour EXPLAIN.

citus.explain_analyze_sort_method (énumération)

Détermine la méthode de tri des tâches dans la sortie de EXPLAIN ANALYZE. La valeur par défaut de citus.explain_analyze_sort_method est execution-time.

Les valeurs prises en charge sont les suivantes :

execution-time : trier par heure d’exécution.
taskId : trier par ID de tâche.

Paramètres PgBouncer managé

Les paramètres PgBouncer managé suivants peuvent être configurés sur un nœud ou un coordinateur unique.

Nom du paramètre	Description	Default
pgbouncer.default_pool_size	Définissez la valeur de ce paramètre sur le nombre de connexions par paire utilisateur/base de données.	295
pgbouncer.ignore_startup_parameters	Liste de paramètres séparés par des virgules que PgBouncer peut ignorer. Par exemple, vous pouvez laisser PgBouncer ignorer le paramètre `extra_float_digits`. Certains paramètres sont autorisés, tous les autres occasionnent une erreur. Cela est nécessaire pour tolérer un JDBC trop enthousiaste qui souhaite définir sans condition « extra_float_digits=2 » dans le paquet de démarrage. Utilisez cette option si la bibliothèque que vous utilisez signale des erreurs telles que `pq: unsupported startup parameter: extra_float_digits`.	extra_float_digits, ssl_renegotiation_limit
pgBouncer.max_client_conn	Définissez la valeur de ce paramètre sur le plus grand nombre de connexions clientes à PgBouncer que vous souhaitez prendre en charge.	2000
pgBouncer.min_pool_size	Ajoutez plus de connexions au serveur pour le pool si le nombre actuel est inférieur à celui défini.	0 (désactivé)
pgBouncer.pool_mode	Définissez cette valeur de paramètre sur TRANSACTION pour le regroupement de transactions (ce qui est le paramètre recommandé pour la plupart des charges de travail).	TRANSACTION
pgbouncer.query_wait_timeout	Durée maximale (en secondes) que les requêtes sont autorisées à passer en attente d’exécution. Si la requête n’est pas affectée à un serveur pendant ce temps, le client est déconnecté.	20 s
pgbouncer.server_idle_timeout	Une connexion de serveur ayant été inactive au-delà de ce nombre de secondes sera fermée. Si la valeur est 0, ce délai d’attente est désactivé.	60s

Paramètres PostgreSQL

DateStyle : définit le format d'affichage des valeurs de date et d'heure
IntervalStyle : définit le format d'affichage des valeurs d'intervalle
TimeZone : définit le fuseau horaire pour l'affichage et l'interprétation des horodatages
application_name : définit le nom de l'application à signaler dans les statistiques et les journaux
array_nulls : permet l'entrée d'éléments NULL dans les tableaux
autovacuum : lance le sous-processus de nettoyage automatique
autovacuum_analyze_scale_factor : nombre d'insertions, de mises à jour ou de suppressions de tuple avant l'analyse, exprimé en fraction de reltuples
autovacuum_analyze_threshold : nombre minimum d'insertions, de mises à jour ou de suppressions de tuple avant l'analyse
autovacuum_naptime : durée de veille entre deux exécutions du nettoyage automatique
autovacuum_vacuum_cost_delay : délai lié au coût du nettoyage, en millisecondes, pour le nettoyage automatique
autovacuum_vacuum_cost_limit : montant du coût du nettoyage disponible avant la mise en veille, pour le nettoyage automatique
autovacuum_vacuum_scale_factor : nombre de mises à jour ou de suppressions de tuple avant le nettoyage, exprimé en fraction de reltuples
autovacuum_vacuum_threshold : nombre minimum de mises à jour ou de suppressions de tuple avant le nettoyage
autovacuum_work_mem : définit la mémoire maximum à utiliser par chaque processus Worker de nettoyage automatique
backend_flush_after : nombre de pages après lequel les écritures précédemment effectuées sont vidées sur le disque
backslash_quote - Définit si le caractère « ’ » est autorisé dans les littéraux de chaîne
bgwriter_delay : durée de veille entre deux cycles de l'enregistreur exécuté en arrière-plan
bgwriter_flush_after : nombre de pages après lequel les écritures précédemment effectuées sont vidées sur le disque
bgwriter_lru_maxpages : nombre maximum de pages LRU à vider par cycle de l'enregistreur exécuté en arrière-plan
bgwriter_lru_multiplier : multiple de l'utilisation moyenne du tampon à libérer par cycle
bytea_output : définit le format de sortie pour bytea
check_function_bodies : vérifie le corps des fonctions pendant l'exécution de CREATE FUNCTION
checkpoint_completion_target : temps passé à vider les tampons dont l'intégrité est compromise lors du point de contrôle, exprimé en fraction de l'intervalle entre deux points de contrôle
checkpoint_timeout : définit le délai maximum entre deux points de contrôle automatiques du WAL
checkpoint_warning : déclenche des avertissements si des segments de point de contrôle sont remplis plus fréquemment
client_encoding : définit l'encodage du jeu de caractères du client
client_min_messages : définit les niveaux des messages envoyés au client
commit_delay : définit le délai, en microsecondes, entre la validation de la transaction et le vidage de WAL sur le disque
commit_siblings : définit le nombre minimum de transactions ouvertes simultanées avant d'exécuter commit_delay
constraint_exclusion : permet au planificateur d'utiliser des contraintes pour optimiser les requêtes
cpu_index_tuple_cost : définit l'estimation par le planificateur du coût de traitement de chaque entrée d'index pendant une analyse d'index
cpu_operator_cost : définit l'estimation par le planificateur du coût de traitement de chaque appel d'opérateur ou de fonction
cpu_tuple_cost : définit l'estimation par le planificateur du coût de traitement de chaque tuple (ligne)
cursor_tuple_fraction : définit l'estimation par le planificateur de la fraction récupérée des lignes d'un curseur
deadlock_timeout : définit la durée d'attente sur un verrou avant de rechercher un blocage, en millisecondes
debug_pretty_print : met en retrait les affichages de l'arborescence d'analyse et de planification
debug_print_parse : consigne l'arborescence d'analyse de chaque requête
debug_print_plan : consigne le plan d'exécution de chaque requête
debug_print_rewritten : consigne l'arborescence d'analyse réécrite de chaque requête
default_statistics_target : définit la cible des statistiques par défaut
default_tablespace : définit l'espace disque logique par défaut où les tables et index doivent être créés
default_text_search_config : définit la configuration par défaut de la recherche de texte
default_transaction_deferrable : définit l'état de report par défaut des nouvelles transactions
default_transaction_isolation : définit le niveau d'isolement de chaque nouvelle transaction
default_transaction_read_only : définit l'état de lecture seule par défaut des nouvelles transactions
default_with_oids : crée de nouvelles tables avec OID par défaut
effective_cache_size : définit l'hypothèse du planificateur concernant la taille du cache de disque
enable_bitmapscan : permet au planificateur d'utiliser des plans d'analyse bitmap
enable_gathermerge : permet au planificateur d'utiliser des plans de regroupement et de fusion
enable_hashagg : permet au planificateur d'utiliser des plans d'agrégation hachée
enable_hashjoin : permet au planificateur d'utiliser des plans de jointure hachée
enable_indexonlyscan : permet au planificateur d'utiliser des plans d'analyse d'index uniquement
enable_indexscan : permet au planificateur d'utiliser des plans d'analyse d'index
enable_material : permet au planificateur d'utiliser la matérialisation
enable_mergejoin : permet au planificateur d'utiliser des plans de jointure de fusion
enable_nestloop : permet au planificateur d'utiliser des plans de jointure de boucles imbriquées
enable_seqscan : permet au planificateur d'utiliser des plans d'analyse séquentielle
enable_sort : permet au planificateur d'utiliser des étapes de tri explicites
enable_tidscan : permet au planificateur d'utiliser des plans d'analyse des TID
escape_string_warning : signale la présence de barres obliques inverses d'échappement dans les littéraux de chaîne ordinaires
exit_on_error : met fin à la session en cas d'erreur
extra_float_digits : définit le nombre de chiffres affichés pour les valeurs à virgule flottante
force_parallel_mode : force l'utilisation de fonctions de requêtes en parallèle
from_collapse_limit : définit la taille de la liste FROM au-delà de laquelle les sous-requêtes ne sont pas réduites
geqo : active l'optimisation génétique des requêtes (GEQO)
geqo_effort : GEQO - un effort est fait pour définir la valeur par défaut d'autres paramètres GEQO
geqo_generations : GEQO - nombre d'itérations de l'algorithme
geqo_pool_size : GEQO - nombre d'individus au sein de la population
geqo_seed : GEQO - seed pour la sélection de chemin aléatoire
geqo_selection_bias : GEQO - pression sélective au sein de la population
geqo_threshold : définit le seuil d'éléments FROM au-delà duquel l'optimisation GEQO est utilisée
gin_fuzzy_search_limit : définit le résultat maximum autorisé pour une recherche exacte par GIN
gin_pending_list_limit : définit la taille maximum de la liste en attente pour l'index GIN
idle_in_transaction_session_timeout : définit la durée maximum d'inactivité autorisée pour toute transaction
join_collapse_limit : définit la taille de la liste FROM au-delà de laquelle les constructions JOIN ne sont pas aplaties
lc_monetary : définit les paramètres régionaux pour le formatage des valeurs monétaires
lc_numeric : définit les paramètres régionaux pour le formatage des nombres
lo_compat_privileges : active le mode de compatibilité descendante pour les vérifications de privilèges sur les objets volumineux
lock_timeout : définit la durée maximum autorisée (en millisecondes) pour toute attente liée à un verrou. 0 désactive ce paramètre
log_autovacuum_min_duration : définit le délai d'exécution minimum au-dessus duquel les actions de nettoyage automatique sont consignées
log_connections : consigne chaque connexion réussie
log_destination : définit la destination de la sortie du journal du serveur
log_disconnections : consigne la fin d'une session, en indiquant sa durée
log_duration : consigne la durée de chaque instruction SQL terminée
log_error_verbosity : définit la verbosité des messages consignés
log_lock_waits : consigne les longues attentes liées à un verrou
log_min_duration_statement : définit la durée d'exécution minimum (en millisecondes) au-dessus de laquelle les instructions sont consignées. -1 désactive les durées des instructions de journalisation
log_min_error_statement : permet de consigner toutes les instructions générant des erreurs à ce niveau ou à un niveau supérieur
log_min_messages : définit les niveaux des messages consignés
log_replication_commands : consigne chaque commande de réplication
log_statement : définit le type d'instructions consignées
log_statement_stats : pour chaque requête, inscrit les statistiques de performances cumulées dans le journal du serveur
log_temp_files : consigne l'utilisation des fichiers temporaires dont la taille est supérieure à ce nombre de kilo-octets
maintenance_work_mem : définit la mémoire maximum à utiliser pour les opérations de maintenance
max_parallel_workers : définit le nombre maximum de Workers parallèles qui peuvent être actifs en même temps
max_parallel_workers_per_gather : définit le nombre maximum de processus parallèles par nœud exécuteur
max_pred_locks_per_page : définit le nombre maximum de tuples verrouillés par prédicat pour chaque page
max_pred_locks_per_relation : définit le nombre maximum de pages et de tuples verrouillés par prédicat pour chaque relation
max_standby_archive_delay : définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur de secours traite des données WAL archivées
max_standby_streaming_delay : définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur de secours traite des données WAL diffusées en continu
max_sync_workers_per_subscription : nombre maximum de Workers de synchronisation de table par abonnement
max_wal_size : définit la taille du WAL qui déclenche un point de contrôle
min_parallel_index_scan_size : définit la quantité minimum de données d'index pour une analyse parallèle
min_wal_size : définit la taille minimum de réduction du WAL
operator_precedence_warning : émet un avertissement pour les constructions qui ont changé de signification depuis PostgreSQL 9.4
parallel_setup_cost : définit l'estimation par le planificateur du coût de démarrage des processus Worker pour l'interrogation en parallèle
parallel_tuple_cost : définit l’estimation par le planificateur du coût du passage de chaque tuple (ligne) du Worker au back-end principal
pg_stat_statements.save : enregistre les statistiques de pg_stat_statements en cas d'arrêt du serveur
pg_stat_statements.track : sélectionne les instructions suivies par pg_stat_statements
pg_stat_statements.track_utility : détermine si les commandes de l'utilitaire sont suivies par pg_stat_statements
quote_all_identifiers : lors de la génération de fragments SQL, délimite tous les identificateurs
random_page_cost : définit l'estimation par le planificateur du coût d'une page de disque récupérée de manière non séquentielle
row_security : active la sécurité des lignes
search_path : définit l’ordre de recherche des schémas pour les noms qui ne sont pas qualifiés par schéma
seq_page_cost : définit l'estimation par le planificateur du coût d'une page de disque récupérée de manière séquentielle
session_replication_role : définit le comportement de la session pour les déclencheurs et les règles de réécriture
standard_conforming_strings : permet aux chaînes « ... » de traiter littéralement les barres obliques inverses
statement_timeout : définit la durée maximum autorisée (en millisecondes) pour toute instruction. 0 désactive ce paramètre
synchronize_seqscans : permet des analyses séquentielles synchronisées
synchronous_commit : définit le niveau de synchronisation de la transaction actuelle
tcp_keepalives_count : nombre maximum de retransmissions TCP Keepalive
tcp_keepalives_idle : délai entre deux transmissions TCP Keepalive
tcp_keepalives_interval : délai entre deux retransmissions TCP Keepalive
temp_buffers : définit le nombre maximum de tampons temporaires utilisés par chaque session de base de données
temp_tablespaces : définit le ou les espaces disque logiques à utiliser pour les tables temporaires et les fichiers de tri
track_activities : collecte des informations sur l'exécution des commandes
track_counts : collecte des statistiques sur l'activité de la base de données
track_functions : collecte des statistiques au niveau des fonctions sur l'activité de la base de données
track_io_timing : collecte des statistiques de minutage pour l'activité d'E/S de la base de données
transform_null_equals : traite « expr = NULL » sous la forme « expr IS NULL »
vacuum_cost_delay : délai lié au coût du nettoyage, en millisecondes
vacuum_cost_limit : montant du coût du nettoyage disponible avant la mise en veille
vacuum_cost_page_dirty : coût du nettoyage pour une page dont l'intégrité est compromise par le nettoyage
vacuum_cost_page_hit : coût du nettoyage pour une page trouvée dans le cache de la mémoire tampon
vacuum_cost_page_miss : coût du nettoyage pour une page introuvable dans le cache de la mémoire tampon
vacuum_defer_cleanup_age : nombre de transactions en fonction desquelles les nettoyages VACUUM et HOT doivent être reportés, le cas échéant
vacuum_freeze_min_age : âge minimum auquel VACUUM doit geler une ligne de la table
vacuum_freeze_table_age : âge auquel VACUUM doit analyser toute la table pour geler les tuples
vacuum_multixact_freeze_min_age : âge minimum auquel VACUUM doit geler un MultiXactId sur une ligne de la table
vacuum_multixact_freeze_table_age : âge Multixact auquel VACUUM doit analyser toute la table pour geler les tuples
wal_receiver_status_interval : définit l'intervalle maximum entre les rapports sur l'état du récepteur WAL
wal_writer_delay : délai entre les vidages WAL effectués dans l'enregistreur WAL
wal_writer_flush_after : quantité de WAL écrite par l'enregistreur WAL qui déclenche un vidage
work_mem : définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d'écrire dans des fichiers des disques temporaires
xmlbinary : détermine comment les valeurs binaires doivent être encodées en XML
xmloption : détermine si les données XML des opérations d'analyse et de sérialisation implicites doivent être considérées comme des documents ou des fragments de contenu

Étapes suivantes

Les options de configurationde ressource d’un cluster sont une autre forme de configuration.
La base de données PostgreSQL sous-jacente a également des paramètres de configuration.

Paramètres de serveur Azure Cosmos DB for PostgreSQL

Paramètres Azure Cosmos DB for PostgreSQL

Configuration générale

citus.use_secondary_nodes (énumération)

citus.cluster_name (texte)

citus.enable_version_checks (booléen)

citus.log_distributed_deadlock_detection (booléen)

citus.distributed_deadlock_detection_factor (virgule flottante)

citus.node_connection_timeout (entier)

citus.log_remote_commands (booléen)

citus.show_shards_for_app_name_prefixes (text)

citus.override_table_visibility (booléen)

citus.use_citus_managed_tables (booléen)

citus.rebalancer_by_disk_size_base_cost (entier)

Statistiques sur les requêtes

citus.stat_statements_purge_interval (entier)

citus.stat_statements_max (entier)

citus.stat_statements_track (énumération)

citus.stat_tenants_untracked_sample_rate

Chargement des données

citus.multi_shard_commit_protocol (énumération)

citus.shard_replication_factor (entier)

Configuration du planificateur

citus.local_table_join_policy (énumération)

citus.limit_clause_row_fetch_count (entier)

citus.count_distinct_error_rate (virgule flottante)

citus.task_assignment_policy (énumération)

citus.enable_non_colocated_router_query_pushdown (booléen)

Transfert des données intermédiaires

citus.max_intermediate_result_size (entier)

DDL

citus.enable_schema_based_sharding

Configuration de l’exécuteur

Général

citus.all_modifications_commutative

citus.remote_task_check_interval (entier)

citus.task_executor_type (énumération)

citus.multi_task_query_log_level (énumération) {#multi_task_logging}

citus.propagate_set_commands (énumération)

citus.create_object_propagation (enum)

citus.enable_repartition_joins (booléen)

citus.enable_repartitioned_insert_select (booléen)

citus.enable_binary_protocol (booléen)

citus.max_adaptive_executor_pool_size (entier)

citus.executor_slow_start_interval (entier)

citus.max_cached_conns_per_worker (entier)

citus.force_max_query_parallelization (booléen)

Configuration de l’exécuteur du suivi des tâches

citus.task_tracker_delay (entier)

citus.max_assign_task_batch_size (entier)

citus.max_running_tasks_per_node (entier)

citus.partition_buffer_size (entier)

Sortie explain

citus.explain_all_tasks (booléen)

citus.explain_analyze_sort_method (énumération)

Paramètres PgBouncer managé

Paramètres PostgreSQL

Étapes suivantes

Ressources supplémentaires