Vous n'êtes pas identifié(e).
Ah oui, petite question supplémentaire : est-ce qu'on peut garder le paramètre wal_sender_timeout à 0 ?
Ou faut-il le ramener à une valeur fixe ?
Bonjour Julien,
Ce qui est compliqué, c'est que c'est un serveur que je n'administre pas directement (support de deuxième niveau). Les versions mineures sont toutes en 10.4.
Nous avons bien redémarré les secondaires (première opération effectuée).
Mais pendant la nuit, le problème s'est résolu, après avoir passé le paramètre wal_sender_timeout à 0 sur le serveur primaire.
On a vu monter la volumétrie dans le répertoire pg_slot du serveur primaire, puis la réplication est repartie et tout le retard s'est rattrapé petit à petit.
En tout cas, merci pour l'aide.
Effectivement, j'ai oublié de préciser que les deux serveurs étaient en v10.
Sur le secondaire, on ne trouve rien dans les logs, ce qui est curieux...
Bonjour,
J'ai un serveur primaire avec une réplication logique définie sur un serveur secondaire.
Hier, un problème de fichier temporaire trop gros sur le primaire a bloqué la réplication du serveur secondaire, bien que le serveur primaire n'ait pas stoppé.
Dans les logs du primaire, on a les lignes suivantes :
ERROR: could not extend file "base/470081886/2605213501.244": No space left on device
ERROR: could not write to data file for XID 86374211: Resource temporarily unavailable
Et depuis, la réplication logique ne fonctionne plus.
La vue pg_stat_replication affiche bien le serveur secondaire, mais il est dans un état "catchup". La colonne sent_lsn montre que le primaire continue d'empiler les WAL, mais les colonnes write_lsn, flush_lsn et replay_lsn restent bloquées à la même valeur. Du coup, les WAL s'empilent sur le principal.
Côté secondaire, la souscription est toujours présente. En revanche, je ne vois pas, dans la liste des processus, de processus walreceiver.
Avez-vous une idée de la façon de débloquer la situation, sans avoir à reconstruire la réplication complète sur le secondaire ?
Merci d'avance pour votre aide.
Je viens de faire la mise à niveau vers la version 12.10.
Un dump au format plain ne résolvait pas le problème.
En revanche, j'ai mis à jour PostGIS (y compris l'extension postgis_raster) et la ligne a disparu du dump.
Ça semblait donc être un bug plutôt au niveau de PostGIS, corrigé par l'upgrade.
Problème résolu. Encore merci pour votre aide à tous les deux.
Cédric
Oui, pg_dump et pg_restore sont bien en version 12.8 tous les deux.
Et non, je n'ai aucun rôle nommé 16430. Par contre, cette valeur est très proche des OID des autres rôles de l'instance.
Le phénomène se produit avec une nouvelle sauvegarde (test effectué ce matin).
Merci pour votre aide à tous les deux.
Non, aucun message d'erreur à la création de la sauvegarde.
C'est très curieux...
Pour info, je suis en v12
Oui, exact, au temps pour moi...
Le résultat est de toute façon le même que sur spatial_ref_sys :
select relowner, relacl from pg_class where relname = 'raster_columns';
relowner | relacl
----------+-----------------------------------------
10 | {postgres=arwdDxt/postgres,=r/postgres}
(1 ligne)Bonjour,
J'ai un serveur dont je fais la sauvegarde par pg_dump et la restauration par pg_restore.
PostGIS est installée comme extension sur le serveur.
Or, lors de la restauration, une erreur apparaît systématiquement lors de la restauration des droits sur la table spatial_ref_sys :
pg_restore: erreur : could not execute query: ERREUR: le rôle « 16430 » n'existe pas
La commande était : REVOKE ALL ON TABLE public.raster_columns FROM "16430";
Dans la vue système pg_role, il n'y a aucun utilisateur avec l'OID 16430 (qui doit correspondre à un utilisateur qui a existé puis a été supprimé, parce que j'ai des utilisateurs avec l'OID 16429 et 16431).
Quand j'affiche les droits sur la table via psql, aucune mention spéciale n'apparaît :
\dp spatial_ref_sys;
Droits d'accès
Schéma | Nom | Type | Droits d'accès | Droits d'accès à la colonne | Politiques
--------+-----------------+-------+---------------------------+-----------------------------+------------
public | spatial_ref_sys | table | postgres=arwdDxt/postgres+| |
| | | =r/postgres | |
(1 ligne)Rien non plus dans les droits d'accès par défaut :
\ddp
Droits d'accès par défaut
Propriétaire | Schéma | Type | Droits d'accès
--------------+--------+------+----------------
(0 ligne)D'où peut venir cette commande de restauration ?
Y a-t-il une solution pour enlever sa génération lors de la sauvegarde ?
Merci d'avance pour votre aide,
Cédric
Parfait. Merci pour les réponses toujours aussi utiles.
Ced
Peut-être plus simple : ma commande pg_basebackup copiant également les fichiers WAL en cours de sauvegarde (pour une sauvegarde consistante), le nettoyage des WAL archivés par pg_receivewal peut se faire pour tout journal de transactions antérieur au plus ancien des WAL copiés par pg_basebackup.
C'est bien ça ?
Merci pour la réponse.
Du coup, je peux, à la fin de chaque pg_basebackup, récupérer le fichier backup_label et le copier dans le répertoire d'archivage des WAL et le renommer avec le nom du WAL en cours d'archivage, avec l'extension .backup. Ça devrait faire la même chose ?
Bonjour,
Je configure la sauvegarde PITR d'un serveur à l'aide de l'outil pg_receivewal pour l'archivage des journaux de transaction et pg_basebackup pour la copie des fichiers de données.
Tout fonctionne très bien, mais la seule chose que je ne vois plus par rapport à une sauvegarde PITR plus "manuelle" (archivage des WAL + copie des fichiers avec appel des fonctions pg_start_backup et pg_stop_backup), c'est le fichier .backup dans le répertoire d'archivage des WAL correspondant à la copie des fichiers.
Or, c'est sur ce type de fichier que s'appuie pg_archivecleanup pour supprimer les WAL qui ne sont plus nécessaires à partir d'une sauvegarde donnée.
Je pense que c'est dû à ma configuration de pg_receivewal, mais je n'ai pas trouvé d'argument en lien avec cette fonctionnalité.
Est-ce que j'ai loupé quelque chose ?
Merci d'avance pour votre aide,
ced
Merci pour ce retour. L'ajout de statistiques sur description ne change effectivement rien au problème de sélectivité.
Pour le test du patch, comme je suis sur un serveur de production en v12, je vais éviter pour l'instant. Mais le problème est visiblement connu.
Merci pour cette piste.
Après essai, il s'avère que ça ne change rien à l'estimation des lignes de la jointure, et donc le nested loop reste privilégié pour les nœuds suivants.
Voici une requête plus complète:
SELECT e.id_ech, d.id_point, p.npp, pl.echelon, p2.csa, d.caracthab, f.caracthab
FROM description d
INNER JOIN echantillon e USING (id_ech)
INNER JOIN point_lt pl USING (id_ech, id_point)
INNER JOIN point p USING (id_point)
INNER JOIN inv_prod.e2point p2 USING (npp)
INNER JOIN inv_prod.g3foret f USING (npp)
WHERE d.caracthab IS NULL;Et le plan d'exécution associé :
Nested Loop (cost=4892.91..16307.31 rows=452 width=34) (actual time=27.204..949.370 rows=79848 loops=1)
-> Hash Join (cost=4892.48..16099.82 rows=452 width=49) (actual time=27.192..601.904 rows=79848 loops=1)
Hash Cond: (d.id_ech = e.id_ech)
-> Nested Loop (cost=4888.30..16094.40 rows=452 width=53) (actual time=27.169..589.386 rows=79848 loops=1)
-> Nested Loop (cost=4887.88..13699.38 rows=5481 width=34) (actual time=27.154..248.767 rows=87137 loops=1)
Join Filter: (d.id_point = p.id_point)
-> Hash Join (cost=4887.45..10633.48 rows=5481 width=21) (actual time=27.139..95.810 rows=87137 loops=1)
Hash Cond: ((pl.id_ech = d.id_ech) AND (pl.id_point = d.id_point))
-> Seq Scan on point_lt pl (cost=0.00..4571.05 rows=223805 width=11) (actual time=0.002..12.972 rows=223805 loops=1)
-> Hash (cost=3569.09..3569.09 rows=87891 width=10) (actual time=27.098..27.099 rows=87137 loops=1)
Buckets: 131072 Batches: 1 Memory Usage: 4428kB
-> Seq Scan on description d (cost=0.00..3569.09 rows=87891 width=10) (actual time=0.004..17.110 rows=87137 loops=1)
Filter: (caracthab IS NULL)
Rows Removed by Filter: 84872
-> Index Scan using pk_point on point p (cost=0.43..0.55 rows=1 width=21) (actual time=0.001..0.001 rows=1 loops=87137)
Index Cond: (id_point = pl.id_point)
-> Index Scan using pkg3foret on g3foret f (cost=0.42..0.44 rows=1 width=19) (actual time=0.003..0.003 rows=1 loops=87137)
Index Cond: (npp = (p.npp)::bpchar)
-> Hash (cost=2.97..2.97 rows=97 width=4) (actual time=0.020..0.020 rows=97 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 12kB
-> Seq Scan on echantillon e (cost=0.00..2.97 rows=97 width=4) (actual time=0.006..0.012 rows=97 loops=1)
-> Index Scan using pke2point on e2point p2 (cost=0.42..0.46 rows=1 width=19) (actual time=0.004..0.004 rows=1 loops=79848)
Index Cond: (npp = (p.npp)::bpchar)
Planning Time: 1.343 ms
Execution Time: 951.515 ms
On voit que le nested loop est privilégié parce que l'estimation du nombre de lignes est sous-évaluée. Je n'ai pas mis toutes les jointures de la requête initiale, mais plus il y a de jointures, plus les nested loop s'empilent et plus ça se dégrade.
En tout cas, merci pour le coup de main.
Comme indiqué, cette requête n'est qu'une partie d'une plus grosse requête.
Or, la sous-estimation du nombre de lignes provoque, sur les opérations suivantes, une cascade de nested loops qui, eux, compte tenu de la sous-estimation du nombre de lignes, entraînent des performances déplorables... En désactivant le nested loop, la plus grosse requête prend moins d'une seconde, là où les nested loops allongent le délai à 23 secondes.
D'où ma recherche d'une solution pour améliorer l'estimation du nombre de lignes au niveau du hash join.
Bonjour,
J'ai une requête SELECT qui a de mauvaises performances, dues au choix, par l'optimiser, de nested loops sur plusieurs nœuds parce que le nombre de ligne est mal estimé.
En simplifiant la requête, j'ai pu isoler la jointure où l'estimation du nombre de lignes est trop basse, ce qui se répercute ensuite sur le reste de la requête.
Voici la jointure en question :
SELECT e.id_ech, d.id_point, pl.echelon, d.caracthab
FROM description d
INNER JOIN echantillon e USING (id_ech)
INNER JOIN point_lt pl USING (id_ech, id_point)
WHERE d.caracthab IS NULL;Et l'explain analyze correspondant:
Hash Join (cost=4891.64..10652.69 rows=5481 width=13) (actual time=48.476..105.321 rows=87137 loops=1)
Hash Cond: (d.id_ech = e.id_ech)
-> Hash Join (cost=4887.45..10633.48 rows=5481 width=17) (actual time=48.414..95.828 rows=87137 loops=1)
Hash Cond: ((pl.id_ech = d.id_ech) AND (pl.id_point = d.id_point))
-> Seq Scan on point_lt pl (cost=0.00..4571.05 rows=223805 width=11) (actual time=0.004..11.601 rows=223805 loops=1)
-> Hash (cost=3569.09..3569.09 rows=87891 width=10) (actual time=48.336..48.337 rows=87137 loops=1)
Buckets: 131072 Batches: 1 Memory Usage: 4428kB
-> Seq Scan on description d (cost=0.00..3569.09 rows=87891 width=10) (actual time=0.009..31.108 rows=87137 loops=1)
Filter: (caracthab IS NULL)
Rows Removed by Filter: 84872
-> Hash (cost=2.97..2.97 rows=97 width=4) (actual time=0.056..0.056 rows=97 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 12kB
-> Seq Scan on echantillon e (cost=0.00..2.97 rows=97 width=4) (actual time=0.011..0.030 rows=97 loops=1)
Planning Time: 0.530 ms
Execution Time: 107.281 ms
Y a-t-il un moyen d'améliorer la sélectivité du hash join (par la création de statistiques par exemple) ? Je sais le faire pour deux colonnes d'une même table, mais entre différentes tables, c'est faisable ?
Merci d'avance pour votre aide,
ced
Oui, la machine physique a des disques locaux et la machine virtuelle des disques sur un SAN.
Pour l'overcommit, voici les paramètres appliqués :
vm.swappiness = 1
vm.overcommit_memory = 2
vm.overcommit_ratio = 99
Bonjour,
Je mène actuellement une série de tests visant à comparer le plus objectivement possible les différences de performances de PostgreSQL entre un serveur physique et un serveur virtuel dimensionné de manière identique (même nombre de CPU , même quantité de RAM). L'objectif est d'évaluer s'il y a des écarts forts entre les deux types de serveurs (comme ce que certains utilisateurs le pressentent) ou pas.
J'ai installé PostgreSQL v11 sur les deux machines et je les ai paramétrées de la même façon (paramètres identiques du fichier postgresql.conf).
J'ai ensuite fait tourner plusieurs benchmarks avec pgbench, ou plus précisément avec pgbench-tools.
J'ai commencé par une série de tests avec des facteurs d'échelle de 1, 10, 100 et 1000 (la base est celle initialisée par défaut dans pgbench). En termes de résultats (TPS et latence), je n'observe aucune différence entre les deux serveurs. Le serveur virtuel serait même un peu plus performant...
J'ai ensuite relancé les tests avec les facteurs 100, 1000 et 10000, histoire de travailler avec une taille de base de données qui ne tienne pas en mémoire (32 GB). Là encore, les résultats des tests (TPS et latence) sont très proches, toutefois le serveur virtuel a mis 2h de plus que le serveur physique pour boucler les tests... Et quand j'analyse les logs avec PgBadger, je vois que les requêtes de type COPY et VACUUM sont plus lentes sur le serveur virtuel.
Mon interprétation est que ce qui ralentit le serveur virtuel, ce sont les écritures de données sur disque. En effet, quand je teste les temps d'écriture / lecture avec l'outil dd, les résultats sont meilleurs sur le serveur physique (180 MB/s vs 120 MB/s). Est-ce que ça vous semble être la bonne analyse ?
Je pense que pgbench ne fait qu'évaluer des performances en mémoire pure (vue que toutes les opérations sont effectuées en mémoire), sans prendre en compte des opérations d'écriture sur les disques (comme les COPY et les VACUUM). C'est bien ça ?
Merci d'avance pour votre aide dans ma compréhension des résultats.
Cédric
Le nombre de CPU (ou "processeurs"), ce qui peut être différent du nombre de cœurs.
Pour connaître ce nombre sur une machine Linux :
cat /proc/cpuinfo | grep processor | wc -lJe m'auto-réponds partiellement...
A priori, c'est parce qu'il y a des services dépendants des services postgresql.
Donc, en arrêtant chaque service, puis en les masquant, j'arrive à les arrêter sans qu'ils puissent repartir tout seul :
sudo systemctl stop postgresql@10-main.service
sudo systemctl stop postgresql@11-main.service
sudo systemctl mask postgresql@10-main.service
sudo systemctl mask postgresql@11-main.serviceEt pour les redémarrer, il faut les démasquer :
sudo systemctl unmask postgresql@10-main.service
sudo systemctl unmask postgresql@11-main.service
sudo systemctl start postgresql@10-main.service
sudo systemctl start postgresql@11-main.serviceMais je ne sais pas si ce que je fais là (qui fournit le résultat attendu) est bien ou pas, et s'il y a une autre façon plus propre de faire ?
Je suis preneur de tout conseil.
Merci d'avance.
Petit complément : j'observe le même redémarrage automatique quand j'exécute un pg_ctlcluster ... stop depuis l'utilisateur postgres.
Bonjour,
Pour faire une montée de version majeure de PostgreSQL sous Debian Stretch, en utilisant pg_upgrade, j'ai besoin d'arrêter les deux instances (une en v10 et une en v11) sur le serveur.
Pour ça, j'utilise la commande :
sudo systemctl stop postgresql.serviceÇa fonctionne : les deux instances s'arrêtent bien.
Mais curieusement, les services se relancent tous seuls au bout d'une ou deux minutes.
Je ne suis pas spécialiste de systemctl (j'ai essayé avec la commande disable, mais ça ne change rien), mais je me doute qu'il doit y avoir une configuration quelque part pour empêcher ce relancement automatique, bien ennuyeux pour poursuivre les opérations de migration.
Comment faire pour empêcher ce redémarrage automatique du service ?
Merci d'avance pour votre aide,
Cédric
OK. Merci pour ton aide.