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
