Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 1C4291337B49 for ; Sun, 8 May 2011 20:04:22 -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 87127-02 for ; Sun, 8 May 2011 23:04:14 +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 5767B13364DE for ; Sun, 8 May 2011 20:04:13 -0300 (ADT) Received: from mailserver.dialdata.com.ar (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id EE0D62E1CF; Sun, 8 May 2011 20:04:07 -0300 (ART) Received: from 190-49-189-125.speedy.com.ar ([190.49.189.125]) by mailserver.dialdata.com.ar:81 with HTTP (HTTP/1.1 POST); Sun, 08 May 2011 20:04:07 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4be838803243af4b5ecd947f24c2f5ad" Date: Sun, 08 May 2011 20:04:07 -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> <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> <549d4022bc9e560e8a4d96f30827f0dc@dialdata.com.ar> Message-ID: X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: EE0D62E1CF.A24DA 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=0.791 tagged_above=-10 required=5 tests=BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201105/13 X-Sequence-Number: 597 --=_4be838803243af4b5ecd947f24c2f5ad Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@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@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@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@dialdata.com.ar --=_4be838803243af4b5ecd947f24c2f5ad Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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

Te comento, ahora tengo la siguiente config:

listen_addresses =3D '*'
wal_level =3D archive
fsync = =3D on
archive_mode =3D off
archive_command =3D 'exit 0'
mai= ntenance_work_mem =3D 480MB
checkpoint_completion_target =3D 0.5
= effective_cache_size =3D 5632MB
work_mem =3D 40MB
wal_buffers =3D= 8MB
checkpoint_segments =3D 30
shared_buffers =3D 1920MB
ma= x_connections =3D 40


desde el servidor postgres me salio esto:
[root@pgsql1 ~]# time php script.php

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


# vmstat 1
 = ;procs      memory      p= age            =         disks     fa= ults         cpu
 r b w&n= bsp;    avm    fre   flt  re&n= bsp; 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&nbs= p; 947  0  0 100
 0 0 0   2378M  6539M&n= bsp;   12   0   0   0  &n= bsp;  0   0 968 969 1913 10863 28650  1  3 96
 0 0 0   2378M  6539M     6 &= nbsp; 0   0   0     0   0= 546 546 1089 6194 16354  0  1 98
 1 0 0   23= 78M  6539M     6   0   0 =   0     0   0 730 728 1454 8227 21740&nb= sp; 1  2 97
 1 0 0   2378M  6538M  =    6   0   0   0   &= nbsp; 4   0 489 491 1001 5603 14838  0  1 98
 = ;0 0 0   2378M  6538M     9   = 0   0   0     0   0 795 7= 93 1584 8949 23630  1  2 97
 1 0 0   2378M&nb= sp; 6538M   280   0   0   0 &n= bsp;   0   0 1196 1197 2385 13374 35302  1  2= 97
 0 0 0   2378M  6538M    11&nbs= p;  0   0   0     0  = ; 0 1264 1264 2517 14127 37221  1  3 96
 0 0 0 &nb= sp; 2378M  6538M    14   0   0 = ;  0     0   0 1190 1190 2378 13306 3513= 4  1  2 96
 0 0 0   2378M  6538M &n= bsp;   8   0   0   0  &nb= sp;  4   0 903 904 1797 10096 26721  1  1 98
=  0 0 0   2378M  6537M     8 &n= bsp; 0   0   0     0   0 = 890 890 1771 9890 26344  0  2 97
 0 0 0   237= 8M  6537M   654   0   0   0&nb= sp;  649   0 1124 1122 2232 12759 33166  1  3 96 0 0 0   2378M  6537M     8&nbs= p;  0   0   0     0  = ; 0 846 846 1690 9494 25190  1  3 97
 0 0 0  = 2378M  6537M    10   0   0 &n= bsp; 0     0   0 885 886 1750 9938 26260 = ; 1  2 97
 0 0 0   2378M  6537M  &n= bsp;  8   0   0   0   &nb= sp; 0   0 875 875 1724 9829 25717  1  2 97
 0= 0 0   2378M  6536M    12   0 =   0   0     0   0 1092 1091 21= 64 12168 32123  1  2 97
 0 0 0   2378M  = 6536M     8   0   0   0&n= bsp;    4   0 921 922 1828 10312 27239  1&nbs= p; 3 96
 0 0 0   2378M  6536M    12=    0   0   0     0 &= nbsp; 0 1103 1103 2190 12341 32564  1  2 97
 0 0 0 = ;  2378M  6536M    10   0   0&= nbsp;  0     4   0 1093 1093 2165 12189 = 32053  1  2 97




y desde el we= bserver:
[root@webserver ~]# time php script.php

r= eal    4m54.846s
user    0m2.695s
s= ys     0m1.775s


# vmstat 1
 = procs      memory      pa= ge            &= nbsp;       disks     fau= lts         cpu
 r b w&nb= sp;    avm    fre   flt  re&nb= sp; pi  po    fr  sr ad4 ad6   in &= nbsp; sy   cs us sy id
 1 0 0   2326M  6= 513M   299   0   0   0   = 310   0 11698   0   79  776 1027  0=   0 100
 0 0 0   2326M  6513M  &nbs= p;  9   0   0   0    = ; 0   0 714 714 2481 6264 19800  1  1 98
 0 0= 0   2326M  6513M     8   0&nb= sp;  0   0     0   0 790 790 2= 739 6879 21811  1  2 97
 0 0 0   2326M  = 6513M     8   0   0   0&n= bsp;    0   0 802 802 2775 6998 22135  1 = ; 1 98
 0 0 0   2326M  6513M   &nbs= p; 4   0   0   0     0&nb= sp;  0 599 599 2096 5273 16803  0  1 98
 0 0 0&nbs= p;  2326M  6513M     6   0 &nb= sp; 0   0     0   0 587 587 2042 51= 77 16343  0  1 99
 1 0 0   2326M  6513M&= nbsp;    5   0   0   0 &n= bsp;   0   0 559 560 1942 4921 15578  0  2 98=
 0 0 0   2326M  6513M     7&n= bsp;  0   0   0     0 &nb= sp; 0 830 831 2886 7251 22945  1  2 97
 0 0 0 &nbs= p; 2326M  6513M     6   0   0&= nbsp;  0     0   0 729 727 2539 6354 202= 57  1  1 98
 0 0 0   2326M  6513M &= nbsp;   6   0   0   0  &n= bsp;  0   0 684 686 2376 6059 18994  1  1 98
=  0 0 0   2326M  6512M     8 &n= bsp; 0   0   0     0   0 = 725 725 2512 6331 20056  1  1 99
 0 0 0   232= 6M  6512M     6   0   0 &= nbsp; 0     0   0 693 691 2409 6061 19221&nbs= p; 0  1 99
 0 0 0   2326M  6512M  &= nbsp;  7   0   0   0   &n= bsp; 0   0 736 737 2590 6485 20617  1  1 98
 = 0 0 0   2326M  6512M    57   0 = ;  0   0     0   0 716 716 248= 2 6285 19817  1  2 97
 0 0 0   2326M  65= 12M   652   0   0   0   6= 37   0 646 645 2246 5864 17975  1  2 98
 0 0 = 0   2326M  6512M     7   0&nbs= p;  0   0    12   0 638 640 2210 56= 17 17730  1  2 97
 0 0 0   2326M  6512M&= nbsp;    5   0   0   0 &n= bsp;   0   0 564 562 1977 4954 15824  0  1 99=
 0 0 0   2326M  6512M     4&n= bsp;  0   0   0     0 &nb= sp; 0 337 338 1177 3028 9576  1  1 99


Si hago:
[root@pgsql1 ~]# dd if=3D/dev/zero of=3D/tmp/test count=3D500000<= br />500000+0 records in
500000+0 records out
256000000 bytes tra= nsferred in 1.938541 secs (132058083 bytes/sec)

El sistema me es= cribió 256 Mb en 1,9 segundos a una velocidad de escritura de 125Mb<= br />
Por eso no creo que sea un problema de discos.

Saludo= s.

 

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



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

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

Perdon, revisando me doy cuenta que interprete mal el vmstat. Tu siste= ma 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 consol= a de postgres me la ejecuta en cuestión de 1 segundo y escribi&oacut= e; bien los datos en disco? yo creo que estoy teniendo mal algo en postgres= =2Econf

Los dos tipos de inserts son muy distintos. En el script haces un inse= rt por transaccion mientras que en el otro haces todos los inserts en una u= nica 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 ant= es de hacer los inserts.
  

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

listen_addresses =3D '*'
wal_level =3D archive
fsync =3D onarchive_mode =3D on
archive_command =3D 'exit 0'

Donde estas escribiendo los archives? Deshabilita el archive_mode a ve= r como afecta tu prueba.


maintenance_work_mem =3D 480MB
checkpoint_completion_target = =3D 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 sistem= a OLAP con inserts intensivos.

effective_cache_size =3D 5632MB
work_mem =3D 40MB
wal_buffers = =3D 4MB

Para scripts como el que estas ejecutando quiza convenga duplicar wal_= buffers.
 

checkpoint_segments =3D 8

Es bajo. Subilo a 30.

shared_buffers =3D 1920MB
max_connections =3D 400

Totalmente al margen: 400 conexiones es excesivo para cualquier sistem= a. Mantene max_connections entre 20 y 50. Mas si estas usando un connection= pooler.
 
Slds.,
Fernando.
 
--=_4be838803243af4b5ecd947f24c2f5ad--