Ton post sur PostgreSQLFr.org
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@postgresql.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:
Show quoted text
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:
Show quoted text
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