Re: [pgsql-fr-generale] Problème de threadPostgresql

Xavier,

Tout d'abord un grand merci d'avoir posté ta news sur PostgreSQLFr.org. Ce n'est
un secret pour personne, je cherche à avoir des personnes qui m'aident dans la
gestion au quotidien de pgfr.org, notament en traduisant les annonces
officielles de PostgreSQL (celles qu'on trouve sur la liste pgsql-announce). Ces
traductions représentent une grosse partie des articles publiés sur ce site.
Bien sûr, nous espérons que cela se diversifie, notament avec des articles
techniques un peu plus fournis...

Je t'écris ce mail pour te dire que je n'ai pas pu publier ton annonce en
l'état, puisqu'elle n'était pas la traduction de l'annonce officielle de la
sortie de la beta4. Pour que je puisse la publier, il aurait fallu que tu fasses
une traduction du mail que je t'ai redirigé sur l'annonce de la béta 4, mail
rédigé par marc fournier.

Tu veras sur le site ma traduction de ce post:
http://www.postgresqlfr.org/?q=node/view/98

Tu remarqueras que mes traductions ne sont pas toujours exactes, j'essaie de
faire au mieux, ce n'est pas mon métier, je ne suis pas linguiste :)

J'espère sincèrement que tu ne m'en voudras pas, mais je te garantis que
j'apprécie réellement ton geste, tu es l'un des trop rares à avoir contribué...

A l'avenir, si tu veux poster sur PG, n'hésite pas! Tout est le bienvenu:
articles, news...

Mais si tu postes une news; assure-toi que ça n'a pas déjà été fait de manière
officielle sur la liste pgsql-announce(at)postgresql(dot)org ( à laquelle je te
reccommande vivement de t'abonner:
http://archives.postgresql.org/pgsql-announce/

Ensuite viens sur l'irc (server irc.freenode.net, canal #postgresqlfr) nous dire
que tu te charges de la traduction de tel ou tel truc, afin de t'assurer qu'on
ne soit pas déjà entrain de le faire... Pour l'instant, nous sommes trop peu
nombreux à le faire et nous n'avons pas mis en place de système de
réservation...

Je poste ce mail en copie vers la liste PostgreSQL Francophone, afin de donner
un petit "mode d'emploi" des posts sur PostgreSQLFr.org :)

Merci encore!!

--
Jean-Paul ARGUDO

Site perso : http://www.argudo.org
PostgreSQL : http://www.postgresqlfr.org
l'APRIL : http://www.april.org

Bonjour,

J'ai depuis plusieurs jours un load important sur un serveur de prod.
Après quelques lectures de logs, il se trouve qu'il n'y a jamais plus de
1 thread postgresql à la fois, et ceci, même en utilisant une
application de stress avec une 50e d'utilisateurs virtuels. A savoir que
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.

Au niveau de la configuration, le serveur est actuellement hébergé chez
OVH qui effectue des opérations de maintenance automatique, mais je n'ai
rien trouvé concernant des modifications de postgres.

Quelqu'un aurait-il une idée ou une direction dans laquelle chercher ?

merci d'avance,
+

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

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

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