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-08 23:04:07
Message-ID: c2e6c76332d3f5a45b36ee6542435f66@dialdata.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: arpug

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

In response to

Responses

Browse arpug by date

  From Date Subject
Next Message Fernando Hevia 2011-05-09 11:34:42 Re: Consulta
Previous Message Fernando Hevia 2011-05-08 02:46:49 Re: Consulta