Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Administrant des bases de données Postgres, je réalise régulièrement les actions suivantes :
- VACUUM VERBOSE ANALYZE
- REINDEX DATABASE
Mais, de manière aléatoire, la réindexation plante le processus PSQL.
Je suis contraint à redémarrer le service.
Ce que je souhaite faire rapidement (demain) est de rendre plus verbeux ma réindexation afin d'analyser les logs et comprendre ce qui se passe.
Etant débutant, pouvez-vous me dire comment faire ?
Commande ou configuration ?
J'échangerai avec un autre service demain, mais je suis seul pour configurer le mode verbeux.
Toutes mes recherches d'informations ne me donnent aucun résultat.
Merci par avance.
Spiffou
Hors ligne
Il n'existe pas de mode verbeux à la commande SQL REINDEX. Vous entendez quoi par "plante psql" ?
Guillaume.
Hors ligne
Bonjour,
Je modifierai les variables ci-dessous du fichier /var/lib/pgsql/9.1/data/postgresql.conf afin d'avoir des logs à analyser :
- log_min_duration_statement = 0
- log_min_messages = debug5
- log_min_error_statement = debug5
Sinon, lorsque ma reindexation plante, la commande n'affiche plus en sortie de lignes supplémentaires sur les bases réindexées.
De plus, en parallèle lors d'un plantage, lorsque j'exécute une commande PSQL, il ne se passe rien. La commande est comme gelée.
Tout rentre dans l'ordre lorsque je redémarre le service postgresql-9.1.
Le plantage est aléatoire sur sa fréquence ou la base concernée.
Si vous avez une idée, je suis preneur.
Merci par avance.
Spiffou.
Hors ligne
Cette configuration de log_min_error_statement ne vous servira à rien. Cela ne vous donnera qu'une ligne correspondant à la requête en erreur... sauf qu'apparemment la requête ne tombe pas en erreur. De même, log_min_duration_statement ne vous apportera rien non plus. Ça pourrait vous tracer cette requête... sauf qu'elle ne se termine pas, or elle n'est tracée qu'à la fin de son exécution.
Seul le log_min_messages à DEBUG5 apportera plus d'infos.
Si la commande semble gelée, c'est peut-être qu'elle attend un verrou pour s'exécuter. Est-ce le cas ? et tant qu'on y est, quelle version de PostgreSQL utilisez-vous ?
Guillaume.
Hors ligne
Merci de votre retour, j'en prends note.
Je ne comprends pas cette notion de verrou.
Ma version de PostgreSQL est 9.1.
Spiffou.
Hors ligne
Pour réindexer un index, il est nécessaire de prendre un verrou exclusif sur la table associée. Si quelqu'un d'autre lit la table en même temps, l'opération d'indexation est mise en attente.
Guillaume.
Hors ligne
Bonjour Gleu,
Lorsque cette opération est réalisée, nous coupons l'accès applicatif aux utilisateurs.
Il n'y a donc que moi qui réalise une opération de réindexation et malgré cela le plantage a lieu.
Ce n'est donc pas, de ma vision, un problème de verrou exclusif à la ressource.
Cette anomalie est-elle visible dans les logs ?
Y-a-t-il une autre piste qui expliquerait mon plantage ?
Merci par avance.
Spiffou.
Hors ligne
Il n'y a pas que l'applicatif qui se connecte au serveur. Il peut y avoir d'autres utilisateurs connectés (un administrateur sur son pgadmin par exemple), il y a le processus autovacuum, etc. Bref, le seul moyen de savoir, c'est de faire un SELECT * FROM pg_stat_activity WHERE waiting au moment du blocage. Ça peut se voir dans les logs si le paramètre log_lock_waits est configuré, mais la requête est plus simple.
Quant à une autre piste pour votre problème, non. Vous n'avez pas de messages d'erreur, donc la commande est en cours d'exécution. Il n'y a que deux possibilités : la réindexation s'exécute et prend beaucoup de temps (ce serait tout à fait normal pour une réindexation) ou la réindexation ne s'exécute (et la seule raison possible est qu'elle est bloquée par un verrou qu'elle n'arrive pas à obtenir).
Guillaume.
Hors ligne
Quand le "plantage" a lieu, la commande PSQL ne se lance pas (gelé), je ne peux donc pas faire un SELECT * FROM pg_stat_activity WHERE waiting;.
Avez-vous une autre idée ?
Le paramètre log_lock_waits est bien configuré.
J'analyserais donc les logs au prochain "plantage" pour confirmer ou infirmer si le problème proviendrait du verrou exclusif.
Merci des réponses apportées.
Spiffou.
Hors ligne
Non, pas d'autres idées.
Guillaume.
Hors ligne
Pages : 1
