Vous n'êtes pas identifié(e).
Pages : 1
Merci à vous deux pour ces explications.
Je comprends mieux maintenant ce seuil de 64MB (32+32 pour 2 process parallèles). On en apprend tous les jours....
Malgré la parallélisation, le seuil des 2GB pour le maintenance_work_mem est bien toujours d'actualité ?
Avec le log_temp_file, on a justement la trace qui me permet de savoir avec certitude que les fichiers générés le sont par la réindexation.
COMMAND:REINDEX - LOG: temporary file:...
Le max_parallel_maintenance_workers est la valeur par défaut, c'est à dire à 2.
Je suis aussi d'accord avec le fait que ces fichiers soient liés au parallélisme.
Je viens de tester en passant max_parallel_maintenance_workers à 0, et effectivement plus de fichier sharedfileset.
Est-ce qu'on pourrait dire qu'avec un maintenance_work_mem inférieur à 64MB, mon reindex est exécuté par un seul thread, alors qu'à partir de 64MB, Postgresql l'exécuterait en mode parallèle ? Dans ce cas pourquoi l'augmentation de maintenance_work_mem aurait un impact sur l'utilisation ou non du mode parallèle ?
Je tatillonne, mais ce n'est vraiment pas clair pour l'instant.....
Merci pour ce retour.
J'ai le log_temp_file à 0, de façon a tracer l'ensemble des fichiers temp créés.
Mon interrogation est lors d'une réindexation complète d'une base. Donc work_mem ne doit pas jouer dans ce cas il me semble.
Bonjour
J'ai un fonctionnement lors de la réindexation d'une base sur une instance PostgreSQL (V12.6) que j'ai du mal à expliquer.
Avec un maintenance_work_mem positionné à '3MB', j'ai des fichiers base/pgsql_tmp/pgsql_tmp??????.? qui sont créés. Jusque la pas de souci.
Avec un maintenance_work_mem positionné à '10MB', je n'ai aucun fichier pgsql_tmp de créé. Ma base est très petite...
Avec un maintenance_work_mem positionné à '63MB', je n'ai aucun fichier pgsql_tmp de créé.
Par contre, en positionnant le maintenance_work_mem à '64MB' ou plus, il y a la création de fichiers base/pgsql_tmp/pgsql_tmp??????.?.sharedfileset/?.?
Pouvez-vous m'expliquer ce comportement de PostgreSQL s'il vous plait ?
Merci pour vos explications
Bonjour ioguix
Merci pour ta réponse.
Je suis d'accord avec toi, lors d'une bascule il est normal qu'il y ait la fin des WAL disponibles à traiter. Je vais rajouter plus de traces dans mon outil lancé par le restore_command pour essayer d'avoir plus d'information sur cette étape.
Pour le retard de réplication, comme nous sommes en bascule volontaire, je contrôle que le secondaire est à jour et je stoppe proprement le primaire de manière à éviter les connexions applicatives sur cette BDD qui doit perdre la production. Une fois ceci, j'engage le promote du secondaire.
Je vous tiens au courant dès que j'ai pu ajouter des traces dans mes outils.
Encore merci
Philippe
Bonjour
Nous utilisons le mode streaming sous plusieurs versions de Postgresql.
Jusqu'à la V11, le passage d'un secondaire en mode R/W par fichier trigger est très rapide. Quelques secondes pas plus.
Par contre, depuis la V12, la bascule de secondaire streaming en primaire (par promote ou par fichier trigger) peut prendre plusieurs minutes en production. Je suis monté à 10mn sans aucune trace particulière dans le fichier de log du secondaire.
Hors production, je n'ai pas pu reproduire le phénomène.
Comme je le disais, aucune trace. Je ne sais absolument pas ce que peut faire l'instance Postgresql pendant cette phase de 'promote'.
Auriez-vous quelques pistes de recherche à me fournir ? Y aurait-il des paramètres qui pourrait expliquer ceci ?
Si vous avez besoin de plus d'informations sur la configuration en place, sur les traces de l'instance, je peux vous fournir cela sans problème.
Merci à tous pour votre aide
Philippe
Bonjour
Pas sur Debian, mais sur CentOS, mais depuis bien longtemps nous avons des machines avec plusieures instances d'installées en version de PostgreSQL différentes. Et tout se passe bien si les variables d'environnement sont correctement configurées.
Cdlt
Tout à fait gleu, je ne sauvegarde pas pg_xlog mais je sauvegarde les WAL du répertoire d'archive des WAL géré par Postgresql. Pour cela, j'utilise le fichier *backup de pg_xlog pour identifier les WAL archivés a embarquer avec la sauvegarde.
Dans le cas particulier des sauvegardes par snapshots sur VM, où c'est une image disque qui est fait par le système, cela implique que l'ensemble des WAL du répertoire d'archive sont inclus dans le snapshot, ce qui n'est forcement pas problématique.
Philippe
Si le serveur est HS, la restauration se fait avec le jeu de données au moment de la sauvegarde (comme pour un pg_dump !!), d'où l'importance de ne pas rater de WAL lors de la sauvegarde. Il faut le nécessaire pour remettre l'instance en service.
Si on veut aller plus loin, et retrouver le jeu de données au moment du crash, il est impératif que tous les WAL archivés le soit sur un serveur distant. Sinon c'est effectivement impossible.
Par contre j'aimerai bien avoir ton avis (expérience) sur la façon de faire les sauvegardes sur des instances gros volumes avec un taux de transactions importants et surtout sur des instances que l'on ne peut stopper.
Merci
En passant par un nouvel environnement:
_ Restauration de la VM sur le nouvel environnement
_ L'instance ne va normalement pas démarrer, il est nécessaire de créer le fichier recovery.conf qui va bien et de la lancer.
_ Lui mettre à disposition les WAL qu'elle demande (Si la sauvegarde est complète, ces WAL seront dedans).
_ Une fois opérationnelle, la stopper
_ Stopper l'ancienne instance, sauvegarder les données si possible (Sauf si pas de place, mais je ne drop jamais de fichier en situation de restauration)
_ Recopier la grappe de données du nouvel environnement sur l'ancien environnement
_ Relancer sur l'ancien environnement
En espérant ne rien avoir oublié.
Philippe
Je suis surpris de cette réponse: "petites bases et peu de transactions, il y a des chances que ça marche." !!!
Si on fait le start_backup, la sauvegarde, le stop_backup et que l'on sauvegarde l'ensemble des WAL générés pendant la sauvegarde, on doit pouvoir dans tous les cas restaurer l'instance, NON ? Je dirais même que quand on a beaucoup de volume, ce type de sauvegardes est tout de même bien plus rapide et tout à fait valide, je me trompe ?
Merci pour vos réponses sur le sujet.
Philippe
Bonjour
Je ne sais pas si dans votre cas c'est possible, mais chez nous le snapshot commence par lancer un de nos outils pour passer l'instance en "start backup", et à la fin du snapshot, le "stop backup" est lancé.
Ensuite lorsque l'on doit repartir sur un snapshot, on rentre dans le cas d'une restauration PITR. Certes nécessitant la création d'un recovery.conf, donc une action manuelle pour redémarrer, mais jusqu'à aujourd'hui tous nos tests ont été concluant sur le sujet.
Bonjour et merci pour ce retour.
Bonne journée à vous.
Bonjour,
Je suis à la recherche des sources de pgbouncer version 1.5 de manière à en interne pouvoir générer nos RPM pour tests de l'outil.
L'url que l'on propose un peu partout ne fonctionne plus: http://pgfoundry.org/projects/pgbouncer/ - Error 404
Pouvez-vous m'indiquer où cela a été déplacé ?
Merci pour vos retour.
Cdlt
La colonne 'backend_start' va te donner l'heure de début de chaque connexion.
select usename, backend_start from pg_stat_activity where datname='mabase';
Pour connaitre le temps d'établissement de la connexion tu peux:
select usename, now() - backend_start from pg_stat_activity where datname='mabase';
Un peu mieux formaté:
select usename, to_char(now() - backend_start,'DD HH24:MI:SS') from pg_stat_activity where datname='mabase';
Bonjour,
La colonne 'usename' de la table pg_stat_activity donne se renseignement:
select * from pg_stat_activity where datname='mabase';
Alors merci bien pour tes informations sur ce sujet.
Cdlt
Bonjour,
Merci 'Gleu' pour cet éclaircissement.
Donc si j'ai bien compris:
_ bgwriter est un processus qui tourne en tâche de fond et qui est lancé au lancement de l'instance,
_ Ce processus traite de manière régulière les Checkpoints
Paramètres: checkpoint_segments, checkpoint_timeout et checkpoint_completion_target,
_ En plus des checkpoints, bgwriter assure en boucle la descente sur disque de buffers au besoin. Le fait t'il aussi pendant la phase de checkpoint: Je regarderai cela.
Paramètres: bgwriter_delay, bgwriter_lru_maxpages et bgwriter_lru_multiplier
Optimisations et règles de fonctionnements
_ Eviter au mieux les écritures de buffers par les backends. Les écritures doivent être prises en charge par le bgwriter, soit en phase de checkpoint soit directement à l'initiative de bgwriter.
_ Empêcher le déclenchement des checkpoints par dépassement du checkpoint_segments. Le déclenchement doit se faire par checkpoint_timeout.
_ Il peut être nécessaire d'augmenter le shared_buffers si bgwriter ne suit pas la charge de modifications en base.
_ Lisser le taux de descentes des buffers sur disque en ajustant les paramètres checkpoint_completion_target et bgwriter*
Etes vous d'accord avec ces explications ?
Avez-vous d'autres points à ajouter concernant le fonctionnement ou le paramétrage ?
Merci à vous
Cdlt
Bonjour,
Dans la table 'pg_stat_bgwriter' on trouve les informations sur les processus qui ont du assurer l'écriture des buffers modifiés:
buffers_checkpoint lorsque c'est le checkpoint qui a fait le travail,
buffers_clean pour bgwriter,
buffers_backend lorsque c'est un processus client.
buffers_checkpoint, facile à comprendre et c'est lui qui doit assurer le maximum.
buffers_backend, tout aussi facile, mais là le compteur doit être faible pour que les backends fassent ce pour quoi ils sont fait: Répondre aux clients rapidement.
Par contre j'ai un plus de mal avec 'buffers_clean'. Comment doit être ce compteur par rapport à buffers_checkpoint ? Pourquoi et à quel moment bgwriter doit-il ou décide t'il d'écrire lui même des buffers ?
Ce que j'ai aussi un peu de mal à comprendre, c'est cette différence faite entre 'checkpoint' et 'bgwriter' !!! Il me semblait que les 'checkpoint' déclenchaient le travail du bgwriter qui lui était tout le temps lancé.... Le principe de fonctionnement de cet ensemble bgwriter et checkpoint n'est pas très clair.
Pouvez-vous m'apporter quelques explications sur le sujet, dans le but de pouvoir plus facilement configurer l'ensemble des paramètres bgwriter et checkpoint du postgresql.conf ?
Merci d'avance.
Cdlt
Merci pour les liens très intéressants.
Bonjour
Je pense ne pas mettre effectivement cette solution en production, mais je vais tout de même la creuser pour ma culture personnelle. Merci pour cette idée.
Je cherchais plus la solution en bloquant certains droits sur certaines tables système pour le user voulu, mais sans succès. Solution pas très propre et risquée aussi, mais bon....
En tout cas, merci pour vos retours.
Bonne journée
Je suis entièrement d'accord. Mais plus je peux protéger mon instance, plus je garantie une qualité de production.
En tout cas merci pour le retour.
C'est bien ce que je craignais. Pas bien terrible en terme de sécurité pour un fonctionnement en environnement mutualisé.
Merci bien pour la réponse rapide.
Bonjour,
Sur un cluster PostgreSQL j'ai plusieurs bases de créées, chacune avec un rôle de connexion dédié. Le cluster étant donc mutualisé, j’ai besoin de limiter les consommations de certaines ressources de manière à éviter qu’une application ne viennent trop perturber les autres. Pour faire simple, je ne veux surtout pas qu’un rôle donné puisse par exemple adapter le paramètre work_mem à ses propres besoin. Donc je ne souhaite pas donner la possibilité aux différents rôles de pouvoir exécuter un ‘alter role <nom_role> set <parametre>=<valeur>’.
Je cherche depuis un petit moment comment cela est faisable, mais sans succès. Quelqu’un aurait-il déjà fait cela ou aurait-il une idée à me communiquer sur le sujet ?
Merci pour vos retours
Pages : 1
