Vous n'êtes pas identifié(e).
Bonjour
Sur nos bases de production Postgresql (8.4.7 ici), 3 opérations de maintenance sont planifiées de manière hebdomadaire (dimanche) au travers de crons. Les crons exécutent un vacuum full analyze et une reindexation des bases à 10h et 15h respectivement
A minuit, tous les jours, on redémarre les tomcat sur les serveurs applicatifs.
Le redémarrage des tomcat a lieu bien après que la fin des opérations de maintenance.
Le lundi, on peut exécuter des requêtes sur les bases de données par accès direct aux serveurs postgresql
Par contre, l'accès aux serveurs bases de données depuis les applications et donc les pools de connexions tomcat ne se font pas correctement : au niveau du serveur bases de données, les requêtes sont bien en cours d'exécution, visibles dans pg_stat_activity mais ne se terminent jamais.
A priori, le vacuum full est largement terminé lors des premières requêtes applicatives (vers 9h)
je n'ai pas vérifié mais ne vois pas bien pourquoi des verrous existeraient encore en matinée alors que les opérations de maintenance se sont terminées la veille au soir, mais ?
Dans la semaine, nous n'avons pas de problème de blocage de requêtes exécutées depuis les applications, sauf le lundi matin (où les opérations de maintenance entrent en jeu)
Pourriez-vous m'aider sur ce sujet ?
Hors ligne
Il est probable que vos soyez confronté à un soucis d'accès disque.
L'ensemble des taches de maintenance effectuées le dimanche anéantissent surement le cache disque fait au niveau de l'OS. (Et si vous utilisez du cache coté java, le restart de tomcat doit impacter celui-ci aussi). Cela peut être une raison de la durée des requêtes, ce n'est pas la seule.
Par contre, l'accès aux serveurs bases de données depuis les applications et donc les pools de connexions tomcat ne se font pas correctement : au niveau du serveur bases de données, les requêtes sont bien en cours d'exécution, visibles dans pg_stat_activity mais ne se terminent jamais.
vous finissez par les 'killer' ? puis le serveur fonctionne correctement ?
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Hors ligne
Merci pour votre réponse
Non c'est beaucoup plus sauvage, pas de kill, mais un redémarrage de Postgresql (stop et start) pour que l'accès soit rétabli.
En fait, lors de l'inaccessibilité des serveurs sgbd, on atteint le nombre maximum de connexions autorisées (et ce nombre est déjà énormes 512 connexions, plus de 500 requêtes en cours)
Hors ligne
Il faudrait pouvoir analyser ces que font les différentes sessions, notamment les verrous qu'elles ont posé, pour savoir si elles se bloquent les unes les autres.
Guillaume.
Hors ligne
Ok, que dois-je regarder précisément dans pg_locks ? grantee à false ?
J'ai une marge de manoeuvre très faible (en terme de réactivité) vu que le problème est en production :-)
Pourriez-vous m'aider à définir la liste des actions/contrôles que je peux réaliser (si cela est possible, de manière çà ce que j'automatise le plus possible les actions au travers de scripts)
Merci de voter aide
Hors ligne
Si vous avez un nouveau blocage, la première chose à faire est de regarder les lignes avec granted à false dans pg_locks. Cela correspond à tous les verrous en attente. À partir de là, vous saurez quel est l'objet en attente. Il y a de fortes chances que ce soit une table verrouillée, vous aurez l'info dans la colonne relation de pg_locks. Avec cette info, récupérez toutes les infos avec granted à true et relation à la valeur précédemment trouvée. Vous devriez en trouver au moins une. Regardez la colonne du mode de verrou (nommée mode), regardez aussi la colonne pid. Avec un select sur pg_stat_activity en filtrant avec procpid et comme valeur celle trouvée sur la colonne pid de pg_locks. Ainsi vous aurez l'utilisateur qui bloque tout le monde et la requête qu'il exécute. Ouf... j'espère n'avoir rien oublié 
Guillaume.
Hors ligne
Merci beaucoup Guillaume
J'espère avoir tout compris , je reviens vers vous la semaine prochaine
Hors ligne
