Re: Consulta

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?

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

Cualquier sugerencia me va a venir bien.

Gracias.

2011/5/6 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> 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.

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:

Links:
------
[1] mailto:elovelle(at)dialdata(dot)com(dot)ar

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 <elovelle(at)dialdata(dot)com(dot)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:
>
> <?php
>
> pg_connect("host=host port=port dbname=db user=user password=pass") or die
> ("No me conecto...");
> for ( $var = 1; $var <= 100000 ; $var++ )
> {
> $sql = "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(at)dialdata(dot)com(dot)ar>
>
>> 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.
>
>

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

2011/5/7 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> 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é un* vmstat 1* en el server de la base mientras ejecutás el script.

Alguna pista tiene que salir de esto.

Slds.,
Fernando.

>
>

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(at)dialdata(dot)com(dot)ar

Ojo: Deshabilitar fsync aplica únicamente en casos muy especiales, como la
restauración inicial de una base de datos. Es un modo de operación insegura
y puede provocar corrupción en la base si hay un crash o corte de luz.

Los tiempos que te pasé son con fsync = on.

Fijate los logs y vmstat que te arrojan con fsync =on mientras corres el
test.

2011/5/7 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> 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 <elovelle(at)dialdata(dot)com(dot)ar>
>
>> 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é un*vmstat 1*en el server de la base mientras ejecutás el script.
> Alguna pista tiene que salir de esto.
> Slds.,
> Fernando.
>
>>
>>
>
>

Ok, con fsync=on directamente a postgres me tardo:

#time php
script.php
real 5m34.471s
user 0m2.527s
sys 0m1.917s

procs memory page
disks faults cpu
r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us
sy id
0 0 0 2336M 7457M 2 0 0 0 0 0 356 356 1260 3185 10173 1 1 98
0 0
0 2336M 7457M 2 0 0 0 0 0 435 435 1515 3853 12193 1 1 98
0 0 0 2336M
7457M 3 0 0 0 0 0 531 532 1843 4668 14781 0 1 98
0 0 0 2336M 7457M 4 0
0 0 0 0 751 752 2605 6544 20742 1 1 98
0 0 0 2336M 7457M 4 0 0 0 0 0
925 923 3238 7997 25565 1 2 98
0 0 0 2336M 7457M 3 0 0 0 0 0 627 628
2183 5503 17403 0 1 99
0 0 0 2336M 7457M 4 0 0 0 4 0 641 641 2193 5575
17673 1 1 98
0 0 0 2336M 7456M 3 0 0 0 0 0 682 681 2340 5949 18812 1 1
98
0 0 0 2336M 7456M 4 0 0 0 0 0 681 683 2382 5964 18988 1 2 98
0 0 0
2336M 7456M 3 0 0 0 0 0 628 628 2180 5491 17401 0 2 98
0 0 0 2336M
7456M 2 0 0 0 0 0 545 544 1906 4787 15182 0 1 99
0 0 0 2336M 7456M 3 0
0 0 8 0 552 552 1910 4829 15343 1 1 98
0 0 0 2336M 7456M 3 0 0 0 0 0
457 458 1608 4092 13009 0 1 99
0 0 0 2336M 7456M 1 0 0 0 0 0 405 403
1409 3596 11401 0 1 98
0 0 0 2336M 7456M 41 0 0 0 0 0 222 224 790 2078
6525 0 0 100
0 0 0 2336M 7456M 3 0 0 0 0 0 693 693 2403 6102 19174 1 1
98
0 0 0 2336M 7456M 5 0 0 0 0 0 828 827 2910 7228 23070 1 2 97
0 0 0
2336M 7456M 3 0 0 0 4 0 715 716 2486 6238 19804 1 3 97
0 0 0 2336M
7456M 4 0 0 0 0 0 733 733 2544 6395 20261 0 1 98
0 0 0 2336M 7456M 636
0 0 0 656 0 532 532 1833 4879 14835 1 1 98
0 0 0 2336M 7455M 2 0 0 0 8
0 598 598 2067 5180 16650 1 1 98
0 0 0 2336M 7455M 3 0 0 0 0 0 667 667
2316 5865 18498 1 1 98
0 0 0 2336M 7455M 6 0 0 0 0 0 880 879 3048 7688
24303 1 2 97
0 0 0 2336M 7455M 27 0 0 0 0 0 758 759 2608 6650 20957 1 1
98
0 0 0 2336M 7455M 4 0 0 0 6 0 715 713 2457 6154 19698 1 1 98
0 0 0
2336M 7455M 9 0 0 0 0 0 176 178 632 1679 5289 0 0 100
0 0 0 2336M 7455M
1 0 0 0 0 0 412 410 1442 3660 11588 1 1 98
0 0 0 2336M 7455M 3 0 0 0 0
0 492 494 1712 4333 13768 1 1 98
0 0 0 2336M 7455M 1 0 0 0 0 0 330 330
1167 2946 9470 0 1 98
0 0 0 2336M 7455M 3 0 0 0 0 0 410 410 1441 3657
11561 0 1 99
0 0 0 2336M 7455M 3 0 0 0 0 0 692 691 2401 6043 19114 0 1
98
1 0 0 2336M 7455M 4 0 0 0 0 0 726 726 2526 6316 20039 1 1 98
0 0 0
2336M 7455M 3 0 0 0 0 0 686 687 2393 5999 19103 1 1 98
0 0 0 2336M
7454M 4 0 0 0 0 0 702 702 2427 6121 19372 1 2 98
0 0 0 2336M 7454M 5 0
0 0 0 0 681 679 2351 5950 18803 0 2 98
0 0 0 2336M 7454M 4 0 0 0 4 0
718 719 2479 6240 19789 0 1 99
0 0 0 2336M 7454M 37 0 0 0 0 0 666 667
2325 5835 18548 1 1 98
0 0 0 2336M 7454M 6 0 0 0 0 0 746 744 2587 6540
20625 1 2 98
0 0 0 2336M 7454M 8 0 0 0 0 0 810 810 2844 7114 22456 1 2
97
0 0 0 2336M 7454M 632 0 0 0 649 0 496 497 1742 4577 13957 0 1 99
0
0 0 2328M 7455M 265 0 0 0 662 0 189 189 677 1795 5696 0 0 99
0 0 0
2328M 7455M 0 0 0 0 0 0 0 0 10 171 456 0 0 100
0 0 0 2363M 7454M 414 0
0 0 161 0 4 4 33 6478 601 2 0 98
0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 7
151 456 0 0 100
0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 18 149 575 0 0 100
0
0 0 2363M 7454M 0 0 0 0 0 0 3 3 10 147 485 0 0 100
0 0 0 2363M 7454M 0
0 0 0 0 0 0 0 6 149 465 0 0 100
0 0 0 2363M 7454M 2 0 0 0 0 0 0 0 7 152
489 0 0 100
0 0 0 2363M 7454M 0 0 0 0 4 0 2 2 24 149 604 0 0 100
0 0 0
2363M 7454M 0 0 0 0 8 0 9 9 22 147 562 0 0 100

LOGS

May 7 20:40:54
pgsql1 postgres[2024] [99998-1] LOG: statement: INSERT INTO tabla (aa,
bb, cc, dd, ee) VALUES ('99997
','99997','99997','99997','99997')
May 7
20:40:54 pgsql1 postgres[2024] [99999-1] LOG: statement: INSERT INTO
tabla (aa, bb, cc, dd, ee) VALUES
('99998
','99998','99998','99998','99998')
May 7 20:40:54 pgsql1
postgres[2024] [100000-1] LOG: statement: INSERT INTO tabla (aa, bb, cc,
dd, ee) VALUES ('9999
9','99999','99999','99999','99999')
May 7 20:40:54
pgsql1 postgres[2024] [100001-1] LOG: statement: INSERT INTO tabla (aa,
bb, cc, dd, ee) VALUES
('1000
00','100000','100000','100000','100000')
May 7 20:41:52 pgsql1
postgres[1954] [5-1] LOG: checkpoint starting: time
May 7 20:44:32
pgsql1 postgres[1954] [6-1] LOG: checkpoint complete: wrote 799 buffers
(0.3%); 0 transaction log file(s) added, 0 removed, 0 recycled;
write
=160.550 s, sync=0.008 s, total=160.562 s

En los logs no me
aparece gran cosa, la verdad que estoy medio perdido.

Saludos

On Sat,
7 May 2011 19:40:37 -0300, Fernando Hevia wrote:

> Ojo: Deshabilitar
fsync aplica únicamente en casos muy especiales, como la restauración
inicial de una base de datos. Es un modo de operación insegura y puede
provocar corrupción en la base si hay un crash o corte de luz.
>
> Los
tiempos que te pasé son con fsync = on.
>
> Fijate los logs y vmstat
que te arrojan con fsync =on mientras corres el test.
>
> 2011/5/7
Ezequiel Lovelle
>
>> 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(at)dialdata(dot)com(dot)ar
[2] mailto:elovelle(at)dialdata(dot)com(dot)ar

2011/5/7 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> Ok, con fsync=on directamente a postgres me tardo:
>
>
> #time php script.php
> real 5m34.471s
> user 0m2.527s
> sys 0m1.917s
>
> procs memory page disks faults
> cpu
> r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us
> sy id
> ...
> 0 0 0 2336M 7454M 8 0 0 0 0 0 810 810 2844 7114 22456
> 1 2 97
> 0 0 0 2336M 7454M 632 0 0 0 649 0 496 497 1742 4577 13957
> 0 1 99
> 0 0 0 2328M 7455M 265 0 0 0 662 0 189 189 677 1795 5696
> 0 0 99
> 0 0 0 2328M 7455M 0 0 0 0 0 0 0 0 10 171 456
> 0 0 100
> 0 0 0 2363M 7454M 414 0 0 0 161 0 4 4 33 6478 601
> 2 0 98
> 0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 7 151 456
> 0 0 100
> 0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 18 149 575
> 0 0 100
> 0 0 0 2363M 7454M 0 0 0 0 0 0 3 3 10 147 485
> 0 0 100
> 0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 6 149 465
> 0 0 100
> 0 0 0 2363M 7454M 2 0 0 0 0 0 0 0 7 152 489
> 0 0 100
> 0 0 0 2363M 7454M 0 0 0 0 4 0 2 2 24 149 604
> 0 0 100
> 0 0 0 2363M 7454M 0 0 0 0 8 0 9 9 22 147 562
> 0 0 100
>
> En estos últimos registros, a partir del que pinté en rojo, me da la
impresión que el script terminó de ejecutar. Sin embargo, la ocupación de
discos sigue al 100%.
Indicaría que tenés algo más ejecutando que te está ocupando todo el ancho
de banda de I/O.

Me voy a fijar, aunque la prueba la hice en los dos postgres de los
nodos, siendo practicamente idéntico en ambos.

Y si ese fuese el caso,
¿porque cuando hago la query en la consola de postgres me la ejecuta en
cuestión de 1 segundo y escribió bien los datos en disco? yo creo que
estoy teniendo mal algo en postgres.conf

te pego lo que tengo
modificado aver si se te ocurre algo.

listen_addresses = '*'
wal_level
= archive
fsync = on
archive_mode = on
archive_command = 'exit
0'

maintenance_work_mem = 480MB
checkpoint_completion_target =
0.7
effective_cache_size = 5632MB
work_mem = 40MB
wal_buffers =
4MB
checkpoint_segments = 8
shared_buffers = 1920MB
max_connections =
400

Gracias nuevamente.

Saludos.

On Sat, 7 May 2011 21:02:53
-0300, Fernando Hevia wrote:

> 2011/5/7 Ezequiel Lovelle
>
>> Ok,
con fsync=on directamente a postgres me tardo:
>>
>> #time php
script.php
>> real 5m34.471s
>> user 0m2.527s
>> sys 0m1.917s
>>
>>
procs memory page disks faults cpu
>> r b w avm fre flt re pi po fr sr
ad4 ad6 in sy cs us sy id
>> ...
>> 0 0 0 2336M 7454M 8 0 0 0 0 0 810
810 2844 7114 22456 1 2 97
>> 0 0 0 2336M 7454M 632 0 0 0 649 0 496 497
1742 4577 13957 0 1 99
>> 0 0 0 2328M 7455M 265 0 0 0 662 0 189 189 677
1795 5696 0 0 99
>> 0 0 0 2328M 7455M 0 0 0 0 0 0 0 0 10 171 456 0 0
100
>> 0 0 0 2363M 7454M 414 0 0 0 161 0 4 4 33 6478 601 2 0 98
>> 0 0 0
2363M 7454M 0 0 0 0 0 0 0 0 7 151 456 0 0 100
>> 0 0 0 2363M 7454M 0 0 0
0 0 0 0 0 18 149 575 0 0 100
>> 0 0 0 2363M 7454M 0 0 0 0 0 0 3 3 10 147
485 0 0 100
>> 0 0 0 2363M 7454M 0 0 0 0 0 0 0 0 6 149 465 0 0 100
>> 0
0 0 2363M 7454M 2 0 0 0 0 0 0 0 7 152 489 0 0 100
>> 0 0 0 2363M 7454M 0
0 0 0 4 0 2 2 24 149 604 0 0 100
>> 0 0 0 2363M 7454M 0 0 0 0 8 0 9 9 22
147 562 0 0 100
>
> En estos últimos registros, a partir del que pinté
en rojo, me da la impresión que el script terminó de ejecutar. Sin
embargo, la ocupación de discos sigue al 100%.
> Indicaría que tenés
algo más ejecutando que te está ocupando todo el ancho de banda de I/O.

Links:
------
[1] mailto:elovelle(at)dialdata(dot)com(dot)ar

2011/5/7 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> Me voy a fijar, aunque la prueba la hice en los dos postgres de los
> nodos, siendo practicamente idéntico en ambos.
>
Perdon, revisando me doy cuenta que interprete mal el vmstat. Tu sistema
esta idle exceptuando por un nivel de context-switches notable. Que mas
corre en ese equipo? Mejor ejecuta el script en el mismo server con la base
para descartar factores externos.

> Y si ese fuese el caso, ¿porque cuando hago la query en la consola de
> postgres me la ejecuta en cuestión de 1 segundo y escribió bien los datos en
> disco? yo creo que estoy teniendo mal algo en postgres.conf
>
Los dos tipos de inserts son muy distintos. En el script haces un insert por
transaccion mientras que en el otro haces todos los inserts en una unica
transaccion. Aparte del ahorro en cpu en parseo hay un gran ahorro en
escritura aleatoria sobre el disco, que es el que hace la diferencia.
Una seteo que te deberia acelerar el script es ejecutar un SET LOCAL
synchronous_commit TO OFF antes de hacer los inserts.

> te pego lo que tengo modificado aver si se te ocurre algo.
>
> listen_addresses = '*'
> wal_level = archive
> fsync = on
> archive_mode = on
> archive_command = 'exit 0'
>
Donde estas escribiendo los archives? Deshabilita el archive_mode a ver como
afecta tu prueba.

>
> maintenance_work_mem = 480MB
> checkpoint_completion_target = 0.7
>
Algun motivo por el cual modificaste el checkpoint_completion_target? Lo
dejaria en 0.5 y en todo caso lo iria bajando en caso de tener un sistema
OLAP con inserts intensivos.

> effective_cache_size = 5632MB
> work_mem = 40MB
> wal_buffers = 4MB
>
Para scripts como el que estas ejecutando quiza convenga duplicar
wal_buffers.

> checkpoint_segments = 8
>
Es bajo. Subilo a 30.

> shared_buffers = 1920MB
> max_connections = 400
>
Totalmente al margen: 400 conexiones es excesivo para cualquier sistema.
Mantene max_connections entre 20 y 50. Mas si estas usando un connection
pooler.

Slds.,
Fernando.

El server es dedicado y no tiene nada corriendo, excepto ntp y ssh
obviamente.
Estube jugando con los parámetros de la config y el único
que me mejora los tiempos es fsync.
Si lo pongo en off mejoro
muchisimo.

Te comento, ahora tengo la siguiente
config:

listen_addresses = '*'
wal_level = archive
fsync =
on
archive_mode = off
archive_command = 'exit 0'
maintenance_work_mem =
480MB
checkpoint_completion_target = 0.5
effective_cache_size =
5632MB
work_mem = 40MB
wal_buffers = 8MB
checkpoint_segments =
30
shared_buffers = 1920MB
max_connections = 40

desde el servidor
POSTGRES me salio esto:
[root(at)pgsql1 ~]# time php script.php

real
3m20.964s
user 0m1.988s
sys 0m1.252s

# vmstat 1
procs memory page
disks faults cpu
r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us
sy id
2 0 0 2378M 6539M 300 0 0 0 312 0 0 0 69 752 947 0 0 100
0 0 0
2378M 6539M 12 0 0 0 0 0 968 969 1913 10863 28650 1 3 96
0 0 0 2378M
6539M 6 0 0 0 0 0 546 546 1089 6194 16354 0 1 98
1 0 0 2378M 6539M 6 0
0 0 0 0 730 728 1454 8227 21740 1 2 97
1 0 0 2378M 6538M 6 0 0 0 4 0
489 491 1001 5603 14838 0 1 98
0 0 0 2378M 6538M 9 0 0 0 0 0 795 793
1584 8949 23630 1 2 97
1 0 0 2378M 6538M 280 0 0 0 0 0 1196 1197 2385
13374 35302 1 2 97
0 0 0 2378M 6538M 11 0 0 0 0 0 1264 1264 2517 14127
37221 1 3 96
0 0 0 2378M 6538M 14 0 0 0 0 0 1190 1190 2378 13306 35134
1 2 96
0 0 0 2378M 6538M 8 0 0 0 4 0 903 904 1797 10096 26721 1 1 98
0
0 0 2378M 6537M 8 0 0 0 0 0 890 890 1771 9890 26344 0 2 97
0 0 0 2378M
6537M 654 0 0 0 649 0 1124 1122 2232 12759 33166 1 3 96
0 0 0 2378M
6537M 8 0 0 0 0 0 846 846 1690 9494 25190 1 3 97
0 0 0 2378M 6537M 10 0
0 0 0 0 885 886 1750 9938 26260 1 2 97
0 0 0 2378M 6537M 8 0 0 0 0 0
875 875 1724 9829 25717 1 2 97
0 0 0 2378M 6536M 12 0 0 0 0 0 1092 1091
2164 12168 32123 1 2 97
0 0 0 2378M 6536M 8 0 0 0 4 0 921 922 1828
10312 27239 1 3 96
0 0 0 2378M 6536M 12 0 0 0 0 0 1103 1103 2190 12341
32564 1 2 97
0 0 0 2378M 6536M 10 0 0 0 4 0 1093 1093 2165 12189 32053
1 2 97

y desde el WEBSERVER:
[root(at)webserver ~]# time php
script.php

real 4m54.846s
user 0m2.695s
sys 0m1.775s

# vmstat 1
procs
memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad4 ad6
in sy cs us sy id
1 0 0 2326M 6513M 299 0 0 0 310 0 11698 0 79 776 1027
0 0 100
0 0 0 2326M 6513M 9 0 0 0 0 0 714 714 2481 6264 19800 1 1 98
0
0 0 2326M 6513M 8 0 0 0 0 0 790 790 2739 6879 21811 1 2 97
0 0 0 2326M
6513M 8 0 0 0 0 0 802 802 2775 6998 22135 1 1 98
0 0 0 2326M 6513M 4 0
0 0 0 0 599 599 2096 5273 16803 0 1 98
0 0 0 2326M 6513M 6 0 0 0 0 0
587 587 2042 5177 16343 0 1 99
1 0 0 2326M 6513M 5 0 0 0 0 0 559 560
1942 4921 15578 0 2 98
0 0 0 2326M 6513M 7 0 0 0 0 0 830 831 2886 7251
22945 1 2 97
0 0 0 2326M 6513M 6 0 0 0 0 0 729 727 2539 6354 20257 1 1
98
0 0 0 2326M 6513M 6 0 0 0 0 0 684 686 2376 6059 18994 1 1 98
0 0 0
2326M 6512M 8 0 0 0 0 0 725 725 2512 6331 20056 1 1 99
0 0 0 2326M
6512M 6 0 0 0 0 0 693 691 2409 6061 19221 0 1 99
0 0 0 2326M 6512M 7 0
0 0 0 0 736 737 2590 6485 20617 1 1 98
0 0 0 2326M 6512M 57 0 0 0 0 0
716 716 2482 6285 19817 1 2 97
0 0 0 2326M 6512M 652 0 0 0 637 0 646
645 2246 5864 17975 1 2 98
0 0 0 2326M 6512M 7 0 0 0 12 0 638 640 2210
5617 17730 1 2 97
0 0 0 2326M 6512M 5 0 0 0 0 0 564 562 1977 4954 15824
0 1 99
0 0 0 2326M 6512M 4 0 0 0 0 0 337 338 1177 3028 9576 1 1 99

Si
hago:

[root(at)pgsql1 ~]# dd if=/dev/zero of=/tmp/test
count=500000
500000+0 records in
500000+0 records out
256000000 bytes
transferred in 1.938541 secs (132058083 bytes/sec)

El sistema me
escribió 256 Mb en 1,9 segundos a una velocidad de escritura de
125Mb

Por eso no creo que sea un problema de discos.

Saludos.

On
Sat, 7 May 2011 23:46:49 -0300, Fernando Hevia wrote:

> 2011/5/7
Ezequiel Lovelle
>
>> Me voy a fijar, aunque la prueba la hice en los
dos postgres de los nodos, siendo practicamente idéntico en ambos.
>
>
Perdon, revisando me doy cuenta que interprete mal el vmstat. Tu sistema
esta idle exceptuando por un nivel de context-switches notable. Que mas
corre en ese equipo? Mejor ejecuta el script en el mismo server con la
base para descartar factores externos.
>
>> Y si ese fuese el caso,
¿porque cuando hago la query en la consola de postgres me la ejecuta en
cuestión de 1 segundo y escribió bien los datos en disco? yo creo que
estoy teniendo mal algo en postgres.conf
>
> Los dos tipos de inserts
son muy distintos. En el script haces un insert por transaccion mientras
que en el otro haces todos los inserts en una unica transaccion. Aparte
del ahorro en cpu en parseo hay un gran ahorro en escritura aleatoria
sobre el disco, que es el que hace la diferencia.
> Una seteo que te
deberia acelerar el script es ejecutar un SET LOCAL synchronous_commit
TO OFF antes de hacer los inserts.
>
> te pego lo que te
>
>>
rchive_mode = on
>> archive_command = 'exit 0'
>> Donde estas
escribiendo los archives? Deshabilita el archive_mode a ver como afecta
tu prueba.
> order-left: #ccc 1px solid; margin: 0px 0px 0px 0.8ex;
padding-left: 1ex;">
>
> maintenance_work_mem = 480MB
>
checkpoint_completion_target = 0.7
> Algun motivo por el cual
modificaste el checkpoint_completion_target?
>
>> uote
class="gmail_quote" style="border-left: #ccc 1px solid; margin: 0px 0px
0px 0.8ex; padding
>
> effective_cache_size = 5632MB
> work_mem =
40MB
> wal_buffers = 4MB
> Para scripts como el que estas ejecutando
quiza convenga duplicar wal_buffers.
>
> checkpoint_
>
>> -left: #ccc
1px solid; margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
>>
>>
shared_buffe
> r />max_connections = 400
> Totalmente al margen: 400
conexiones es excesivo para cualquier sistema. Mantene max_connections
entre 20 y 50. Mas si estas usando un connection pooler.
>
>>
>
>>

Links:
------
[1] mailto:elovelle(at)dialdata(dot)com(dot)ar

2011/5/8 Ezequiel Lovelle <elovelle(at)dialdata(dot)com(dot)ar>

> El server es dedicado y no tiene nada corriendo, excepto ntp y ssh
> obviamente.
> Estube jugando con los parámetros de la config y el único que me mejora los
> tiempos es fsync.
> Si lo pongo en off mejoro muchisimo.
>
> ...
>
> Si hago:
>
> [root(at)pgsql1 ~]# dd if=/dev/zero of=/tmp/test count=500000
> 500000+0 records in
> 500000+0 records out
> 256000000 bytes transferred in 1.938541 secs (132058083 bytes/sec)
>
> El sistema me escribió 256 Mb en 1,9 segundos a una velocidad de escritura
> de 125Mb
>
> Por eso no creo que sea un problema de discos.
>
>
125 Mbps de escritura es imposible de lograr con los discos que tenés. El
máximo debe rondar los 35 Mbps secuenciales. Es un caché el que te está
brindando los 125 Mbps.
No conozco de freebsd y no se qué más puede estar afectando tu sistema. En
tu config no veo nada que justifique los tiempos que estás experimentando.
Si bien lograste bajar de 20 a 4 min, todavía me sigue pareciendo bastante.
Y la diferencia de 1'20" en la ejecución desde el webserver me resulta más
raro todavía. Algo no está bien pero no se decirte que puede ser.
Se me ocurre bloating... probá truncando la tabla y luego reintentar las
pruebas a ver si te arroja mejores tiempos.

También te recomiendo postear en la lista pgsql-performance (en inglés) que
es específica para este tipo de consultas.

Saludos.

Voy a probar de instalar postgres en Debian a ver que pasa, muchas
grácias por la ayuda. me fue bastante útil.

Saludos.

On Mon, 9 May
2011 08:34:42 -0300, Fernando Hevia wrote:

> 2011/5/8 Ezequiel Lovelle

>
>> El server es dedicado y no tiene nada corriendo, excepto ntp y
ssh obviamente.
>> Estube jugando con los parámetros de la config y el
único que me mejora los tiempos es fsync.
>> Si lo pongo en off mejoro
muchisimo.
>>
>> ...
>> Si hago:
>>
>> [root(at)pgsql1 ~]# dd
if=/dev/zero of=/tmp/test count=500000
>> 500000+0 records in
>>
500000+0 records out
>> 256000000 bytes transferred in 1.938541 secs
(132058083 bytes/sec)
>>
>> El sistema me escribió 256 Mb en 1,9
segundos a una velocidad de escritura de 125Mb
>>
>> Por eso no creo
que sea un problema de discos.
>
> 125 Mbps de escritura es imposible
de lograr con los discos que tenés. El máximo debe rondar los 35 Mbps
secuenciales. Es un caché el que te está brindando los 125 Mbps.
> No
conozco de freebsd y no se qué más puede estar afectando tu sistema. En
tu config no veo nada que justifique los tiempos que estás
experimentando. Si bien lograste bajar de 20 a 4 min, todavía me sigue
pareciendo bastante. Y la diferencia de 1'20" en la ejecución desde el
webserver me resulta más raro todavía. Algo no está bien pero no se
decirte que puede ser.
> Se me ocurre bloating... probá truncando la
tabla y luego reintentar las pruebas a ver si te arroja mejores tiempos.

>
> También te recomiendo postear en la lista pgsql-performance (en
inglés) que es específica para este tipo de consultas.
>
> Saludos.

Links:
------
[1] mailto:elovelle(at)dialdata(dot)com(dot)ar