Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 67CF61337BB4 for ; Sat, 7 May 2011 16:38:49 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 43009-04 for ; Sat, 7 May 2011 19:38:41 +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 5AFC91337990 for ; Sat, 7 May 2011 16:38:41 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id E0FDC2E1CF; Sat, 7 May 2011 16:38:35 -0300 (ART) Received: from [192.1.3.192] by 192.1.3.1 with HTTP (HTTP/1.1 POST); Sat, 07 May 2011 16:38:35 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f60f50476ea18a0109a3ca4e7466ced0" Date: Sat, 07 May 2011 16:38:35 -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> Message-ID: <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: E0FDC2E1CF.A0449 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=4.315 tagged_above=-10 required=5 tests=BAYES_50=0.8, FUZZY_AMBIEN=0.552, 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/5 X-Sequence-Number: 589 --=_f60f50476ea18a0109a3ca4e7466ced0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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. Saludos. On Sat, 7 May 2011 15:45:58 -0300, Fernando Hevia wrote: > Este fue mi tiempo: > > $ time php test.php > > real 0m42.020s > user 0m1.604s > sys 0m1.448s > > Como notarás, le llevó 1.6 seg de CPU, los otros 40 segundos se la pasó esperando a los discos. > Este sistema tiene 2 cores de 1.86Ghz y dos discos SATA 7200 en RAID 1. En I/O prácticamente idéntico al tuyo. > Si estás en 10 minutos, evidentemente tenés otro problema, posiblemente un lock sobre la tabla. > > Solo para que compares la enorme diferencia en tiempos que puede haber entre un método y otro, fijate lo que tardó esta operación que genera exactamente el mismo resultado: > > pgbench=# timing > Timing is on. > pgbench=# insert into temporal select generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),generate_series(1, 100000); > INSERT 0 100000 > Time: 1089.893 ms > > Los 100 mil inserts es la manera más ineficiente que existe. Por ahí si detallas mejor cuál es el objetivo te podemos dar algunas ideas sobre como hacerlo más eficiente. > > Saludos, > Fernando. > > 2011/5/6 Ezequiel Lovelle > >> Mas o menos me tardo unos 10 minutos o un poco mas, si queres lo vuelvo a ejecutar y te paso el tiempo exacto >> >> el script php simplemente es asi: >> >> pg_connect("host=host port=port dbname=db user=user password=pass") or die ("No me conecto..."); >> for ( $var = 1; $var >> >> Los discos son 2 Caviar Black en RAID 1 >> >> Sludos. >> >> On Fri, 6 May 2011 21:28:23 -0300, Fernando Hevia wrote: >> >>> 2011/5/6 Ezequiel Lovelle >>> >>>> Buenas a todos!, les voy a hacer una pregunta, un poco genérica así que no voy a entrar en grandes detalles. >>>> >>>> Tengo una bbdd en postgres 9.0 con SO Freebsd 8.2, el server es un xeon Quad core de unos 8 Gb de ram y esta configurado para usarlos, como también los parámetros del kernel obviamente. >>>> >>>> Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) con php un bucle que me hace 100000 INSERTS en una tabla con 3 campos y los valores que inserto son solo numeros autoincrementales. >>>> >>>> ¿Cuanto seria aprox un tiempo normal para que me haga todos los inserts? >>> >>> Ni idea. ¿Cuanto te tarda actualmente? Si te interesa compartir tu script puedo ejecutarlo en mis sistemas y comparar datos. >>> La velocidad en inserts dependen más del sistema de I/O que tengas a que la cantidad y velocidad de tus procesadores. >>> >>>> Si tuviese la necesidad, ¿como podria hacer grandes cargas de datos? en el menor tiempo posible obviamente >>> >>> 1. Usa copy >>> 2. Deshabilita fsync >>> 3. Deshabilita índices y claves foráneas antes del insert. >>> Saludos, >>> Fernando. Links: ------ [1] mailto:elovelle@dialdata.com.ar [2] mailto:elovelle@dialdata.com.ar --=_f60f50476ea18a0109a3ca4e7466ced0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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

Saludos.

On Sat, 7 May 2011 15:45:58 -0300, Fernando Hevia wrote:

 

Este fue mi tiempo:
$ time php test.php
real    0m42.020s
user    0m1.604s
sys     0m1.448s
Como notarás, le llevó 1.6 seg de CPU, los otros 40 segu= ndos se la pasó esperando a los discos.
Este sistema tiene 2 cores de 1.86Ghz y dos discos SATA 7200 en RAID 1= =2E En I/O prácticamente idéntico al tuyo. 
Si estás en 10 minutos, evidentemente tenés otro problem= a, posiblemente un lock sobre la tabla.
Solo para que compares la enorme diferencia en tiempos que puede haber= entre un método y otro, fijate lo que tardó esta operaci&oac= ute;n que genera exactamente el mismo resultado:
pgbench=3D# \timing
Timing is on.
pgbench=3D# insert into temporal select generate_series(1, 100000),gen= erate_series(1, 100000),generate_series(1, 100000),generate_series(1, 10000= 0),generate_series(1, 100000);
INSERT 0 100000
Time: 1089.893 ms
Los 100 mil inserts es la manera más ineficiente que existe. Po= r ahí si detallas mejor cuál es el objetivo te podemos dar al= gunas ideas sobre como hacerlo más eficiente.
Saludos,
Fernando.


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

Mas o menos me tardo unos 10 minutos o un poco mas, si queres lo vuelvo = a ejecutar y te paso el tiempo exacto

el script php simplemente es asi:

pg_connect("host=3Dhost  port=3Dport dbname=3Ddb user=3Duser passwo= rd=3Dpass") or die ("No me conecto...");
for ( $var =3D 1; $var <= =3D 100000 ; $var++ )
{
$sql =3D "INSERT INTO server (aa, bb, cc,= dd, ee) VALUES ('$var','$var','$var','$var','$var')";
pg_query($sql);=
}
?>

Los discos son 2 Caviar Black en RAID 1

Sludos.

On Fri, 6 May 2011 21:28:23 -0300, Fernando Hevia wrote:



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

Buenas a todos!, les voy a hacer una pregunta, un poco genérica a= sí que no voy a entrar en grandes detalles.

Tengo una bbdd en postgres 9.0 con SO Freebsd 8.2, el server es un xeon = Quad core de unos 8 Gb de ram y esta configurado para usarlos, como tambi&e= acute;n los parámetros del kernel obviamente.

Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on php un bucle que me hace 100000 INSERTS en una tabla con 3 campos y los = valores que inserto son solo numeros autoincrementales.

¿Cuanto seria aprox un tiempo normal para que me haga todos los i= nserts?

Ni idea. ¿Cuanto te tarda actualmente? Si te interesa compartir= tu script puedo ejecutarlo en mis sistemas y comparar datos.
La velocidad en inserts dependen más del sistema de I/O que ten= gas a que la cantidad y velocidad de tus procesadores.
 

Si tuviese la necesidad, ¿como podria hacer grandes cargas de dat= os? en el menor tiempo posible obviamente

1. Usa copy
2. Deshabilita fsync
3. Deshabilita índices y claves foráneas antes del inser= t.
Saludos,
Fernando.

 

--=_f60f50476ea18a0109a3ca4e7466ced0--