Dénouement : J'ai enfin trouvé toutes les réponses à mes questions via la comande REINDEX.
Merci à "Jean-Christophe Arnu" (s'il passe par ici) qui a confirmé via son article sur http://www.postgresqlfr.org/?q=node/view/49 la solution que j'avais cherché depuis quelques temps. "Froggy / Froggy Corp." wrote: > > Le serveur actuelle ayant que 256Mo de RAM, j avais supprimé il y a > plusieurs mois les connexions persistantes. > > Mais en pratique, après une petite gaffe de ma part, j avais un très bon > load, et ceci en connexion non persistantes. > > Actuellement, je n'utilise plus de connexion persistantes. Mais au final > je me demande si ce n'ai pas juste un problème de tuning car après la > suppression/restauration d'une table utilisateur, j etais passé d'un > load de 3-4 à moins de 1. > > Daniel Verite wrote: > > > > Froggy / Froggy Corp. writes > > > > > l'id du thread change constement, donc le serveur kill/créé un log à > > > chaque affichage de page pratiquement. > > > Le même test a été effectué sur un serveur de test, et là je me > > > retrouve bien avec x threads postgres. > > > > Vérifier les paramètres pgsql.allow_persistent et pgsql.max_persistent du > > fichier php.ini, à supposer que les connexions soient faites avec > > pg_pconnect() ? > > > > PS: il ne s'agit pas de threads mais de processus, postgresql n'utilisant pas > > les threads. > > > > -- > > Daniel > > PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html