Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id CC8111337B67 for ; Sat, 7 May 2011 21:13:07 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 63613-04 for ; Sun, 8 May 2011 00:12:50 +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 7056A1337990 for ; Sat, 7 May 2011 21:12:49 -0300 (ADT) Received: from mailserver.dialdata.com.ar (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id E579B2E1CF; Sat, 7 May 2011 21:12:44 -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); Sat, 07 May 2011 21:12:44 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2b51ba3b093fcfa696f9dd428fa75376" Date: Sat, 07 May 2011 21:12:44 -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> Message-ID: <549d4022bc9e560e8a4d96f30827f0dc@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: E579B2E1CF.AF705 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/11 X-Sequence-Number: 595 --=_2b51ba3b093fcfa696f9dd428fa75376 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@dialdata.com.ar --=_2b51ba3b093fcfa696f9dd428fa75376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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

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

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'

mainten= ance_work_mem =3D 480MB
checkpoint_completion_target =3D 0.7
effe= ctive_cache_size =3D 5632MB
work_mem =3D 40MB
wal_buffers =3D 4MB=
checkpoint_segments =3D 8
shared_buffers =3D 1920MB
max_con= nections =3D 400

Gracias nuevamente.

Saludos.

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



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

Ok, con fsync=3Don directamente a postgres me tardo:


#t= ime php script.php
real    5m34.471s
user &nb= sp;  0m2.527s
sys     0m1.917s

&nb= sp;procs      memory     = page           &nbs= p;        disks     = faults         cpu
 r b = w     avm    fre   flt  r= e  pi  po    fr  sr ad4 ad6   in&nb= sp;  sy   cs us sy id
 ...
 0 0 0 &= nbsp; 2336M  7454M     8   0  = 0   0     0   0 810 810 2844 7114 = 22456  1  2 97
 0 0 0   2336M  7454M&nbs= p;  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&= nbsp; 0 99
 0 0 0   232= 8M  7455M     0   0   0 &= nbsp; 0     0   0   0   0=    10  171  456  0  0 100
 = 0 0 0   2363M  7454M   414   0 &nbs= p; 0   0   161   0   4   = 4   33 6478  601  2  0 98
 0 0 0 &n= bsp; 2363M  7454M     0   0   = 0   0     0   0   0 =   0    7  151  456  0  0 100
&= nbsp;0 0 0   2363M  7454M     0 &nb= sp; 0   0   0     0   0&n= bsp;  0   0   18  149  575  0 = 0 100
 0 0 0   2363M  7454M   &nb= sp; 0   0   0   0     0&n= bsp;  0   3   3   10  147  485=   0  0 100
 0 0 0   2363M  7454M &n= bsp;   0   0   0   0  &nb= sp;  0   0   0   0    6&n= bsp; 149  465  0  0 100
 0 0 0   2363M&n= bsp; 7454M     2   0   0  = ; 0     0   0   0   0&nbs= p;   7  152  489  0  0 100
 0 0 0&= nbsp;  2363M  7454M     0   0 =   0   0     4   0   = 2   2   24  149  604  0  0 100
 0 0 0   2363M  7454M     0 &= nbsp; 0   0   0     8   0=    9   9   22  147  562  0&nbs= p; 0 100

En estos últimos registros, a partir del que pinté en ro= jo, 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 es= tá ocupando todo el ancho de banda de I/O.
--=_2b51ba3b093fcfa696f9dd428fa75376--