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
