Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Locks "sous transactions" » 25/08/2020 13:04:42
Merci pour le retour,
Ce qui me parait étrange, c'est que lorsque le problème apparait, cela impacte des requêtes/transactions/traitements applicatifs bien différents. Même s'il y a une probabilité, j'ai du mal à penser que toutes ces sessions sont en "SubtransControlLock" en même temps. J'ai l’impression que le problème est global alors que de ce que je comprends des "SubtransControlLock", il devrait être local à la session (une transaction donnée ouvre trop de sous transactions).
#2 Général » Locks "sous transactions" » 19/08/2020 11:30:46
- pitpoule
- Réponses : 2
Bonjour,
Depuis quelques jours, nous subissons des contentions sur notre BDD de production (PG 9.6), dûs à des locks de sous transactions (SubtransControlLock). De ce que j'ai compris, chaque transaction peut ourvir 64 sous transactions.
Quand le problème survient, ce n'est pas une seule requête qui "coince" mais tout un ensemble, et dès fois des requêtes qui n'ont rien à voir entre elles (qui correspondent à des périmètres de l'application bien différents), comme si ce compteur était plutôt global que local à une transaction. J'ai du mal à remonter à l'origine du problème.
Est ce qu'il y a un moyen de suivre/tracer ces sous transactions ?
Merci
#3 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 02/06/2020 15:47:15
En tout cas , merci à vous, je comprends mieux ce qu'il se passe et je vais pouvoir agir.
#4 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 22:53:14
Cela vaut pour les colonnes de l'index mais aussi pour les colonnes utilisées dans des expressions.
Que je comprenne bien , les expressions dans les index ?
#5 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 16:04:14
dverite,
Je pense, en effet, que l'on est dans la cas de figure impliquant la libc
Ancien serveur primaire:
- Debian 8.11
- libc 2.19
Nouveau serveur primaire, après bascule:
- Debian 10.4
- libc 2.28
En dehors du problème de la contrainte UNIQUE, est ce que qu'il faut reconstruire tous les index basés sur une colonne text ?
#6 Re : Général » Contrainte UNIQUE mais doublon dans des tables » 01/06/2020 12:12:28
Je ne comprends absolument pas comment s'est possible.
Pour les colonnes de type texte, Il suffit d'avoir le COLLATE basé une locale qui s'appelle pareil mais qui ne trie pas pareil entre le primaire et le secondaire. C'est pourquoi le primaire et le secondaire devraient avoir exactement le même OS dans la même version.
Sur linux il y a une MAJ majeure récente de la libc qui a accru le risque ces derniers temps, cf https://blog-postgresql.verite.pro/2018 … grade.html
quand on ne réindexe pas suite à un upgrade, ou quand le couple (primaire,secondaire) a des versions décalées de la libc.
En effet, une des colonnes de la clé unique est un champ text.
#7 Général » Contrainte UNIQUE mais doublon dans des tables » 29/05/2020 17:23:52
- pitpoule
- Réponses : 8
Bonjour,
Suite à une bascule d'une base standby en primaire, nous nous retrouvons avec des doublons sur une table malgré une contrainte UNIQUE. La bascule s'est passé normalement.
Nous sommes sur une version pg 9.6.18. Le seul fait notable est que nous avons en même temps upgradé d'une version 9.6.15 en 9.6.18
Sur tous les doublons, nous avons une ligne avec une date d'avant la bascule et une autre d'après (nous avons des colonnes d'horodatage).
Je ne comprends absolument pas comment s'est possible.
Merci pour votre aide
#8 Re : Réplication » Slony en 2020 » 27/03/2020 13:10:37
Les triggers sont très léger, ils sont juste la pour bloquer l'écriture quand on est sur le répliqué.
Pourquoi prendre slony quand la répli native de PG12 fait le taf ?Toutes mes réplications sont en slony mais j'aimerais passer à PG12 un jour
Car je veux répliquer des données de 9.6 -> 12
J'ai essayé aussi pglogical mais je fais face à des problèmes de saturations de fichiers wal sur disque, dû à notre activité: transactions longues + beaucoup DDL
#9 Re : Réplication » Slony en 2020 » 20/02/2020 15:51:06
Pour remettre un peu mon besoin dans son contexte, j'ai d'abord essayé de mettre en place pglogical pour "exporter" les tables. La mise en production a été problématique car notre BDD fait tourner des traitements qui génèrent des transactions longues impliquant des update massifs. On a rapidement été confronté à des saturations de fichiers WAL sur disque, lié au slot de réplication. On a du faire marche arrière. C'est pour cela que je suis parti sur slony.
Ce qui m'inquiète aussi, ce sont les performances car slony met en place des triggers, j'ai peur que cela ralentissent fortement les traitements d'update.
#10 Re : Réplication » Slony en 2020 » 14/02/2020 15:34:22
Il y a au moins un changement lié à pg12: https://github.com/ssinger/slony1-engin … 5b7f4ebe0a
Peut-être ont-ils juste oublié de marquer cette version comme suportée ailleurs dans le code.
De ce que j'ai testé, ça fonctionne.... et plutôt bien même d'ailleurs 
Le truc , c'est que je trouve cet outil complexe.... et je voudrais avoir un avis général dessus avant d'investir plus d'énergie et de temps. Je me posais aussi la question de sa viabilité.
#11 Réplication » Slony en 2020 » 14/02/2020 11:36:28
- pitpoule
- Réponses : 10
Bonjour,
Je suis en train d'étudier la mise en place de Slony pour externaliser un ensemble de tables d'un PG 9.6 vers un PG12. J'ai l'impression que le projet est à moitié vivant/mort. Sur le site, on voit que la dernière version est compatible avec PG 12 mais quand on fait l'install, on a un message indiquant que la 12 n'est pas supportée.
Est ce qu'il est pertinent d'utiliser encore cet outil pour de la prod sur des versions récentes de PG ? Est ce que certains d'entre vous l'ont mis en production récemment ?
Merci
#12 Re : Général » Problème sur requete UPDATE avec select for update » 04/12/2019 15:34:14
Qu'un LIMIT 1 ramène plus qu'une ligne parait assez extraordinaire.
je pense que c'est plutôt le "returning" de l'update qui retourne plusieurs lignes
#13 Re : Général » Prise en compte d'un index par le planificateur » 27/08/2019 11:24:30
Difficile de vous dire autre chose dans ce cas. PostgreSQL n'a besoin de rien (normalement) pour utiliser un index, comme le montre d'ailleurs, si je comprend bien, le fonctionnement des autres plateformes. Il doit y avoir une différence entre cette plateforme et les autres pour qu'elle se comporte autrement. Difficile de savoir quoi si on ne peut pas reproduire le problème ou si on n'a pas les mains sur le serveur.
Je me doute que c'est difficile de trouver au travers de posts d'un forum 
Sinon à votre connaissance, est ce que ce comportement pourrait être expliqué par: une très forte activité sur la table ? un paramétrage du moteur particulier ? une corruption d'une table système quelconque ? un paramétrage particulier de l'OS ?
#14 Re : Général » Prise en compte d'un index par le planificateur » 27/08/2019 10:25:26
Quelque chose l'empêche de l'utiliser vu que, même en désactivant les parcours séquentiels, il préfère toujours un parcours séquentiel. Que donne un "\d ma_table" après création de l'index ?
Si vous sauvegardez la table, et que vous la restaurez sur un autre serveur, le problème est reproductible ? si oui, est-il possible d'avoir ce fichier de sauvegarde pour tenter de reproduire le problème ?
le \d ne donne rien de particulier, l'index est valide
Le truc, c'est que ce n'est pas la première fois que je rencontre ce problème...d'où mon post. Le planificateur finit toujours par utiliser l'index mais pas immédiatement. Sur les autres environnements (dev,recette, préprod), je n'ai jamais eu ce souci. Ce n'est pas lié à la table en particulier, c'est global à l'instance de mon point de vue.
Pour vous fournir un fichier de sauvegarde, c'est compliqué, ce sont des données de paiements.
#15 Re : Général » Prise en compte d'un index par le planificateur » 27/08/2019 09:03:15
Il n'y a pas de preuve formelle de ça dans l'explain analyze, mais pas non plus de preuve du contraire. Mais c'est une des raisons principales de non-prise en compte d'un index (avec les tables trop petites) parce que c'est un scénario typique: création de table vide, chargement, select.
Sinon, une autre piste: ces CREATE INDEX seraient faits dans une session non committée.
Il se trouve que dans ce qu'on voit ci-dessus, les CREATE INDEX ne sont pas montrés contrairement aux autres commandes. Pour quelle raison? Si vous les faites dans une autre session, avec un autre outil, ça pourrait avoir un rapport avec le problème.
L'index est bien "commité" et valide
#16 Re : Général » Prise en compte d'un index par le planificateur » 27/08/2019 09:02:13
Désolé gleu, voici les tests manquants
EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (305683);
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (305683);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6313.63 rows=1 width=74) (actual time=0.488..274.712 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 0
Buffers: shared hit=13040
-> Parallel Seq Scan on ma_table (cost=0.00..5313.53 rows=1 width=74) (actual time=0.319..274.474 rows=1 loops=1)
Filter: (col_id = 305683)
Rows Removed by Filter: 1012963
Buffers: shared hit=13040
Planning time: 0.030 ms
Execution time: 274.724 ms
(10 rows)
toto=> create index on ma_table(col_id);
CREATE INDEX
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (305683);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6391.82 rows=1 width=74) (actual time=0.626..113.348 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 3
Buffers: shared hit=13109
-> Parallel Seq Scan on ma_table (cost=0.00..5391.72 rows=1 width=74) (actual time=45.652..70.369 rows=0 loops=4)
Filter: (col_id = 305683)
Rows Removed by Filter: 253241
Buffers: shared hit=13109
Planning time: 0.295 ms
Execution time: 113.373 ms
(10 rows)
toto=> set max_parallel_workers_per_gather to 0;
SET
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (305683);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------
Seq Scan on ma_table (cost=0.00..13975.94 rows=1 width=74) (actual time=0.355..248.830 rows=1 loops=1)
Filter: (col_id = 305683)
Rows Removed by Filter: 1012966
Buffers: shared hit=13040
Planning time: 0.036 ms
Execution time: 248.845 ms
(6 rows)
toto=> set enable_seqscan to off;
SET
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (305683);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
Seq Scan on ma_table (cost=10000000000.00..10000013975.94 rows=1 width=74) (actual time=0.391..265.597 rows=1 loops=1)
Filter: (col_id = 305683)
Rows Removed by Filter: 1012967
Buffers: shared hit=13040
Planning time: 0.044 ms
Execution time: 265.616 ms
(6 rows)
#17 Re : Général » Prise en compte d'un index par le planificateur » 26/08/2019 09:15:17
Voici le résultat des différents tests
Sans l'index
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (8438);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6200.20 rows=1 width=74) (actual time=0.253..419.457 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 0
Buffers: shared hit=12875
-> Parallel Seq Scan on ma_table (cost=0.00..5200.10 rows=1 width=74) (actual time=0.010..419.084 rows=1 loops=1)
Filter: (col_id = 8438)
Rows Removed by Filter: 1009620
Buffers: shared hit=12875
Planning time: 0.045 ms
Execution time: 419.475 ms
(10 rows)
Je crée l'index, pas de prise en compte
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (8438);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6358.91 rows=1 width=74) (actual time=0.335..167.624 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 3
Buffers: shared hit=12944
-> Parallel Seq Scan on ma_table (cost=0.00..5358.81 rows=1 width=74) (actual time=70.830..107.629 rows=0 loops=4)
Filter: (col_id = 8438)
Rows Removed by Filter: 252406
Buffers: shared hit=12944
Planning time: 0.138 ms
Execution time: 167.644 ms
Je lance un analyze sur la table, idem
toto=> analyze verbose ma_table;
INFO: analyzing "ma_table"
INFO: "ma_table": scanned 12875 of 12875 pages, containing 1009623 live rows and 2125 dead rows; 30000 rows in sample, 1009623 estimated total rows
ANALYZE
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (8438);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6358.66 rows=1 width=74) (actual time=0.229..99.608 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 3
Buffers: shared hit=12944
-> Parallel Seq Scan on ma_table (cost=0.00..5358.56 rows=1 width=74) (actual time=42.118..63.982 rows=0 loops=4)
Filter: (col_id = 8438)
Rows Removed by Filter: 252406
Buffers: shared hit=12944
Planning time: 0.173 ms
Execution time: 99.628 ms
(10 rows)
Je lance un vacuum analyze sur la table, pas mieux
toto=> vacuum analyze ma_table;
VACUUM
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (8438);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6358.66 rows=1 width=74) (actual time=0.228..80.305 rows=1 loops=1)
Workers Planned: 3
Workers Launched: 3
Buffers: shared hit=12944
-> Parallel Seq Scan on ma_table (cost=0.00..5358.56 rows=1 width=74) (actual time=37.382..55.064 rows=0 loops=4)
Filter: (col_id = 8438)
Rows Removed by Filter: 252405
Buffers: shared hit=12944
Planning time: 0.133 ms
Execution time: 80.325 ms
(10 rows)
vacuum full et là l'index est pris en compte
toto=> vacuum full analyze verbose ma_table;
INFO: vacuuming "ma_table"
INFO: "ma_table": found 0 removable, 1009808 nonremovable row versions in 12875 pages
DETAIL: 186 dead row versions cannot be removed yet.
CPU 0.14s/1.02u sec elapsed 1.91 sec.
INFO: analyzing "ma_table"
INFO: "ma_table": scanned 12686 of 12686 pages, containing 1009622 live rows and 186 dead rows; 30000 rows in sample, 1009622 estimated total rows
VACUUM
toto=> EXPLAIN (ANALYZE,BUFFERS) SELECT col1 FROM ma_table WHERE col_id IN (8438);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using ma_table_col_id_idx on ma_table (cost=0.42..0.64 rows=1 width=74) (actual time=0.045..0.045 rows=1 loops=1)
Index Cond: (col_id = 8438)
Buffers: shared hit=5 read=2
Planning time: 0.182 ms
Execution time: 0.062 ms
(5 rows)
#19 Re : Général » Prise en compte d'un index par le planificateur » 23/08/2019 17:04:23
ok, je ferai le test
J'ai déjà constaté ce problème de non prise en compte immédiate d'un index pour d'autres tables. Au final, en attendant un peu, le plan de la requête change et l'index est bien utilisé.... mais ce n'est pas immédiat et ça, je ne comprends pas pourquoi.
Je me suis demandé si le problème ne venait pas du paramétrage des coûts du planificateur dans le postgresql.conf, ils sont assez spécifiques sur notre base, notamment:
seq_page_cost = 0.1 # measured on an arbitrary scale
random_page_cost = 0.1 # same scale as above
#20 Re : Général » Prise en compte d'un index par le planificateur » 23/08/2019 14:16:07
J'avais déjà lancé un analyze avant, même un vacuum analyze, sans succès
Daniel, à quoi voyez vous que le planificateur n'avait pas de statistique ?
Merci
#21 Re : Général » Prise en compte d'un index par le planificateur » 23/08/2019 09:15:06
La requête est vraiment basique
Au départ, je créé l'index, le plan ne change pas
toto=> EXPLAIN ANALYZE SELECT col1, col_id
FROM la_table WHERE col_id IN (13);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Gather (cost=1000.00..6956.66 rows=1 width=16) (actual time=77.157..91.363 rows=0 loops=1)
Workers Planned: 3
Workers Launched: 3
-> Parallel Seq Scan on la_table (cost=0.00..5956.56 rows=1 width=16) (actual time=62.873..62.874 rows=0 loops=4)
Filter: (col_id = 13)
Rows Removed by Filter: 250006
Planning time: 0.063 ms
Execution time: 91.389 ms
(8 rows)
Je lance le vacuum full et là, il est pris en compte
toto=> vacuum FULL ANALYZE verbose la_table;
INFO: vacuuming "la_table"
INFO: "la_table": found 0 removable, 1001757 nonremovable row versions in 19242 pages
DETAIL: 1729 dead row versions cannot be removed yet.
CPU 0.14s/0.59u sec elapsed 1.13 sec.
INFO: analyzing "la_table"
INFO: "la_table": scanned 12584 of 12584 pages, containing 1000028 live rows and 1729 dead rows; 30000 rows in sample, 1000028 estimated total rows
VACUUM
toto=> EXPLAIN ANALYZE SELECT col1, col_id
FROM la_table WHERE col_id IN (13);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using la_table_col_id_idx on la_table (cost=0.42..0.64 rows=1 width=16) (actual time=0.080..0.080 rows=0 loops=1)
Index Cond: (col_id = 13)
Planning time: 0.160 ms
Execution time: 0.098 ms
(4 rows)
Est ce qu'il y a un cache des plans ?
#22 Général » Prise en compte d'un index par le planificateur » 22/08/2019 09:26:22
- pitpoule
- Réponses : 18
Bonjour,
La question peut paraître étrange mais à quel moment la création d'un index est prise en compte par le planificateur ? J'ai constaté ce phénomène plusieurs fois sur notre BDD de prod (v 9.6) . Je créé un index, le planificateur (en tout cas l'explain analyze) continue à faire des seq scan.. j'ai tenté de passer un vacuum analyze, le plan ne change pas.
Au final, j'ai lancé un vacuum full sur la table et là , l'index est utilisé. Et cet index est vraiment utile, on gagne un facteur 100 sur le temps d'exécution.
Merci
#23 Re : Réplication » Nombreux locks sur base de standby » 25/06/2019 09:38:03
Un petit retour sur ce sujet.
A priori ce problème de locks reflétait une "saturation" au niveau de la base de secours. Nous avons corrigé une requête et réécrite une autre, ce qui a grandement amélioré les temps de traitement.... et le problème n'est plus survenu.
#24 Re : Réplication » Nombreux locks sur base de standby » 11/06/2019 17:16:32
Alvaro propose en effet de recompiler le serveur mais en lisant le thread dans son intégralité, on voit que 1. cette solution ne concerne que le serveur primaire (donc pas les standbys), et 2. que la solution réelle a été de trouver et supprimer la transaction longue sur le primaire. Bref, si ce thread est réellement en corrélation avec votre problème, cherchez si vous avez des transactions longues non terminées sur le primaire quand vous avez ce soucis sur le secondaire.
Des longues transactions, on en a tout le temps, malheureusement....je vais regarder de ce côté
Merci !
#25 Re : Réplication » Nombreux locks sur base de standby » 11/06/2019 16:15:44
Jamais rencontré ce problème. Recompiler le serveur pour ce problème me paraît hautement douteux. D'où vient cette solution ?
postgresql.org !