Re: Consulta

From: Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>
To: Fernando Hevia <fhevia(at)gmail(dot)com>
Cc: Arpug <arpug(at)postgresql(dot)org>
Subject: Re: Consulta
Date: 2011-05-07 19:38:35
Message-ID: 3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: arpug

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(at)dialdata(dot)com(dot)ar
[2] mailto:elovelle(at)dialdata(dot)com(dot)ar

In response to

Responses

Browse arpug by date

  From Date Subject
Next Message Fernando Hevia 2011-05-07 20:09:59 Re: Consulta
Previous Message Fernando Hevia 2011-05-07 18:45:58 Re: Consulta