Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id DE55E1337B92 for ; Sat, 7 May 2011 18:27:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 10691-01-6 for ; Sat, 7 May 2011 21:27:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailserver.dialdata.com.ar (dialdata.com.ar [200.49.210.5]) by mail.postgresql.org (Postfix) with ESMTP id 8D4811337C23 for ; Sat, 7 May 2011 18:27:06 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id B905B2E1CF; Sat, 7 May 2011 18:27:01 -0300 (ART) Received: from [192.1.3.192] by 192.1.3.1 with HTTP (HTTP/1.1 POST); Sat, 07 May 2011 18:27:01 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_feeeb92e16bcff79d28f22cf9bb93422" Date: Sat, 07 May 2011 18:27:01 -0300 From: Ezequiel Lovelle To: Fernando Hevia Cc: Arpug Subject: Re: Consulta Organization: Teleservicios y Marketing S.A In-Reply-To: References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> Message-ID: <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: B905B2E1CF.AD656 X-DDM-MailScanner: Found to be clean X-DDM-MailScanner-From: elovelle@dialdata.com.ar X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.763 tagged_above=-10 required=5 tests=BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=1.808, RCVD_NUMERIC_HELO=1.164, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: *** X-Archive-Number: 201105/7 X-Sequence-Number: 591 --=_feeeb92e16bcff79d28f22cf9bb93422 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Puse fsync = off #time php script.php real 0m50.592s user 0m1.744s sys 0m1.243s Mejoro bastante, en cuanto pueda te paso lo de los logs, ¿alguna idea de algún otro parámetro para tocar? On Sat, 7 May 2011 17:09:59 -0300, Fernando Hevia wrote: > 2011/5/7 Ezequiel Lovelle > >> Gracias por tu respuesta, se que no es una manera eficiente pero es que quiero testear la bbdd en todos los aspectos. >> >> Te comento, cuando lo hago desde la consola de postgres me da lo siguiente: >> >> bbdd=> timing >> El despliegue de duración está activado. >> bbdd=> INSERT INTO tabla (aa, bb, cc, dd, ee) VALUES (generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000)); >> INSERT 0 100000 >> Duración: 1486,699 ms >> >> Ahí veo que me funciono perfecto, me ganas por unos ms jeje. (destaco que en realidad esto es todo detrás de un pgpool conectado con 3 nodos, no a una bbdd postgres directa) Pero el resultado fue bueno. >> >> El problema es cuando lo hago con php desde un webserver, me tarda lo siguiente: >> >> #time php script.php >> >> real 22m21.733s >> user 0m1.846s >> sys 0m1.902s >> >> Un problema de red no creo que sea ya que todos estos servers de testeo estan en una red separada de la mia en un switch de 100M. >> >> Lo que me hace pensar que el problema es la velocidad del procesamiento de php en el webserver... cosa que me parace muy rara. Igualmente voy a hacer el mismo script en bash o perl aver si es un problema de php. > > 22 minutos es una barbaridad. > > Habilitá log_checkpoints y log_lock_waits en postgres.conf. > Fijate que dicen los logs de postgres mientras ejecutás los inserts. > > Y corré unVMSTAT 1en el server de la base mientras ejecutás el script. > > Alguna pista tiene que salir de esto. > > Slds., > Fernando. > >> Links: ------ [1] mailto:elovelle@dialdata.com.ar --=_feeeb92e16bcff79d28f22cf9bb93422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Puse fsync =3D off

#time php script.php

real    0m50.592s
user    0m1.744ssys     0m1.243s

Mejoro bastante, en cuanto pueda te paso lo de los logs, ¿al= guna idea de algún otro parámetro para tocar?

On Sat, 7 May 2011 17:09:59 -0300, Fernando Hevia wrote:

 



2011/5/7 Ezequiel Lovelle <elovelle@dialdata.com.ar>

Gracias por tu respuesta, se que no es una manera eficien= te pero es que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duración est&Atil= de;¡ activado.
bbdd=3D> INSERT INTO tabla (aa, bb, cc, d= d, ee) VALUES (generate_series(1, 100000),generate_series(1, 100000),genera= te_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000))= ;
INSERT 0 100000
Duración: 1486,699 ms

Ahí veo que me funciono perfecto, me ganas por unos ms jeje. (des= taco que en realidad esto es todo detrás de un pgpool conectado = ;con 3 nodos, no a una bbdd postgres directa) Pero el resultado fue bueno= =2E

El problema es cuando lo hago con php desde un webserver, me tarda = lo siguiente:

#time php script.php

real    22m21.733s
user    0m1.846ssys     0m1.902s

Un problema de red no creo que sea ya que todos estos servers de testeo = estan en una red separada de la mia en un switch de 100M.

Lo que me hace pensar que el problema es la velocidad del procesamiento = de php en el webserver... cosa que me parace muy rara. Igualmente voy = a hacer el mismo script en bash o perl aver si es un problema de php= =2E

22 minutos es una barbaridad. 
Habilitá log_checkpoints y log_lock_waits en postgres.conf.
Fijate que dicen los logs de postgres mientras ejecutás los ins= erts. 
Y corré unvmstat 1en el server de la base mien= tras ejecutás el script.
Alguna pista tiene que salir de esto.
Slds.,
Fernando.

 

 

--=_feeeb92e16bcff79d28f22cf9bb93422--