Vous n'êtes pas identifié(e).
Pages : 1
J'ai oublié de le préciser dans mon premier message, j'avais désactivé l'autovacuum tout comme le fsync pendant le chargement.
Et oui effectivement, il fallait bien prendre en compte les potentiels processus d'autovacuum.
Morale de l'histoire, prendre le temps de bien paramétrer la mémoire.
Bravo Messieurs.
C'est effectivement cela.
Un collègue m'a préconisé de modifier le shared_buffers à 5 Gb et la maintenance_work_mem à 6Gb.
Avec ces modifications, le chargement a été réalisé avec succès.
En espérant que cette discussion aide d'autres.
Merci à tous.
Merci beaucoup pour ce retour.
Processus tué par une autre personne, effectivement ça pourrait être cela sachant que je ne suis pas le seul à accéder au serveur. De plus, sur la précédente tentative de chargement , il me semble (de mémoire) avoir eu un signal 6 «aborted».
Lorsque vous dites que le serveur pourrait être à cour de mémoire, vous parlez d'espace disque ou de RAM ?
Le serveur Red Hat 7 a 16gb de RAM.
Je n'ai pas utilisé plusieurs job (pas de -j X).
J'analyserai la commande dmesg à mon arrivée.
Merci encore Marc.
Bonjour à tous,
Je souhaite charger un export réalisé avec pg_dump sur une base vierge.
Après avoir lancé la commande pg_restore, j'ai ce message d'erreur suivant dans le fichier de log :
LOG: server process (PID 20226) was terminated by signal 9: Killed
DETAIL: Failed process was running: CREATE INDEX idx_name ON table_name USING btree (c1, c2, c3)
Le chargement s'est arrêté au bout de 3 heures. Et les tables ne sont pas présente (sûrement dû à un rollback de l'opération).
Le log de ma commande indique :
Pg_restore: [archiver (db) ] could not execute query: server closed the connexion unexpectedly
Est-ce que quelqu'un aurait une idée de la provenance de l'erreur ?
Il s'agit d'un environnement utilisé par beaucoup d'utilisateurs métier avec un caractère critique...
Infos :
Shared_buffers = 12gb
Maintenance_work_mem = 10gb
Wal_keep_segments = 20
Max_wal_size = 1gb
Fsync = off
Volume de la base ~ 215 gb
Version de PostgreSQL : 9.5
Merci à tous.
Merci pour vos réponses gleu.
Oui j'ai bien compris qu'une mise à jour en version 10 est la solution la plus simple et la plus pérenne.
Reste à voir si cela sera prévue assez rapidement.
Merci pour vos réponses.
Une personne expérimentée sur Postgresql, me conseille :
1) migrer en version 10 pour mettre en place la réplication logique. L'instance d'archivage I2 s'abonnerait aux INSERT et UPDATE de I1.
2) si pas de migration possible, peut-être voir une solution basée sur des triggers. En déclarant I2 table externe, les déclencheurs créés sur I1 reproduiraient les INSERT et UPDATE sur I2. Mais ceci dépend des fréquences d'ecritures journalières...
3) utiliser un outil communautaire.
Pour le point 3, j'ai répertorié pglogical qui (d'après la documentation) permet de filtrer la réplication avec une granularité sur les ordres. C'est à dire : réplique uniquement INSERT et UPDATE.
La personne à qui j'ai exposé le problème m'oriente vers Slony à condition qu'il puisse filtrer la réplication.
Donc mes questions sont :
Est-ce que Slony permet de répliquer uniquement les ordres INSERT et UPDATE ?
Est-ce qu'une personne parmi vous a déjà mis en place Pglogical (en production si possible) ? Quels sont vos retex svp ? J'ai beaucoup de mal avec sa documentation.
Merci à tous.
Merci pour votre réactivité.
La réplication (ou l'archivage) concerne toute les tables de la base de Instance1.
--> quelques soit la modification jouée sur I1, elle devra se faire sur I2. Sauf les suppressions qui seront seulement dûes à la purge.
Il n'y a pas de contraintes critique sur la mise à jour de I2. Elle pourrait s'aligner une fois par jour par exemple.
Et concernant la purge, quelques tables ne seront pas concernées.
--> On purge tout sauf quelques tables.
Bonjour à tous,
J'aimerais obtenir vos avis concernant la mise en œuvre d'une stratégie d'archivage de données.
La stratégie est la suivante :
Instance1 possède 4 années de données alimentée et mise à jour par une application.
Je souhaiterais :
1) Obtenir une instance (Instance2) qui contiendrait une sauvegarde complète de Instance1.
2) supprimer quotidiennement les données de Instance1 de plus d'un an
3) rejouer les transactions de Instance1 sur Instance2 excepté la purge quotidienne de Instance1.
Je pensais mettre en oeuvre une réplication par flux de Instance1 vers Instance2 mais je crains que la purge quotidienne appliquée sur I1 sera rejouée sur Instance2.
Alors que l'objectif de I2 est de conserver les données jusqu'à 4 ans.
Autre idée: toujours en réplication par flux,
Exporter les données à purger sur une autre base avant la purge.
Puis les importer sur I2 après purge.
--> dans ce cas, a-t-on le droit d'écrire sur une instance secondaire ? N'est ce pas trop compliquer à gérer cela ?
Avez vous des idées et des suggestions à proposer pour réaliser chaque étape ?
Ou une proposition pour une autre solution ?
Si un outil permet de faciliter ce genre de gestion je serais bien intéressé ?
La version de Postgresql est la 9.5 sur Red Hat 7.1
Merci à tous.
Le plan tZFG sort bien 54 lignes. C'est celui de la requête avec l'option buffers comme demandé par gleu.
C'est le plan de la requête complète avec la jointure (que je n'ai pas posté) qui sort 124 lignes.
J'ai modifié l'indexation en positionnant des indexes multi-colonnes (c3, c1, c2) puis (c4, c2)
Le résultat est surprenant ~500ms.
Je vous remercie pour vos éclaircissements.
Pour être précis, voici la requête complète :
select t1.c1, t1.c2 from MaTable t1
left outer join Table t3
on t1.c1=t3.c1
where t1.c3='string'
and t1.c2=(select max(t2.c2) from MaTable t2 where t2.c4=t1.c4);
La modification de la première partie de la requête me sors moins de lignes qu'avec le select max.
Merci pour vos réponses.
@dverite
Vous préconisez d'utiliser DISTINCT ON(id) + tri pour la sous requête ?
Tout à fait il y a un index sur la colonne c1 que je viens de supprimer car l'index sur c2 s'avère plus efficace.
@gleu
Je viens de paramétrer comme vous m'avez indiqué.
Voici le nouveau plan d'exécution avec les modifications citées :
https://explain.depesz.com/
La requête en question :
select t1.c1, t1.c2 from MaTable t1
where t1.c3='string'
and t1.c2=(select max(t2.c2) from MaTable t2 where t2.c4=t1.c4);
Bonjour à tous,
Suite à une migration d'Oracle vers PostgreSQL, une requête sous postgre dure 10 fois plus longtemps (50 sec).
J'aimerais savoir quels sont les moyens d'améliorer le temps d'exécution.
Le vacuum est activé, la commande analyze n'est pas oubliée non plus.
Merci.
Pages : 1
