From manager@pro-soft.com.ar Sun May 2 15:04:58 2010 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A9959632B5E for ; Sun, 2 May 2010 12:34:12 -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 90820-04 for ; Sun, 2 May 2010 15:34:05 +0000 (UTC) X-Greylist: delayed 00:29:04.795361 by SQLgrey-1.7.6 Received: from server.facson.com (server.facson.com [74.55.45.242]) by mail.postgresql.org (Postfix) with ESMTP id B9DA463245D for ; Sun, 2 May 2010 12:34:05 -0300 (ADT) Received: from [190.138.181.113] (helo=VALUED92EC3B5D) by server.facson.com with esmtpa (Exim 4.67) (envelope-from ) id 1O8ZXJ-0005vK-Qy for arpug@postgresql.org; Sun, 02 May 2010 10:48:46 -0300 From: "Julio Lechuga - ProSoft" To: Subject: Consulta Date: Sun, 2 May 2010 12:04:58 -0300 Message-ID: <4494B2D02FF5486EA4ACE2E615871EB7@VALUED92EC3B5D> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CAE9EF.B073B8F0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcrqCNR808SqTXc1RceMf6lQAcdTdA== X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.571 tagged_above=-10 required=5 tests=BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77 X-Spam-Level: * X-Archive-Number: 201005/1 X-Sequence-Number: 403 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01CAE9EF.B073B8F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit En principio estoy interesado en algun curso de PgSql Tambien me gustaria aderir a la lista Saludos Julio Lechuga (011)4443-4337 (011) 15-5003-4168 ------=_NextPart_000_0029_01CAE9EF.B073B8F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
En = principio estoy=20 interesado en algun curso de PgSql
 
Tambien me gustaria aderir = a la=20 lista
 
 
Saludos
 

Julio Lechuga

(011)4443-4337

(011) 15-5003-4168

 


__________ Information from ESET NOD32 = Antivirus, version of virus signature database 4978 (20100326) = __________

The message was checked by ESET NOD32 = Antivirus.

http://www.eset.com
------=_NextPart_000_0029_01CAE9EF.B073B8F0-- From reingart@gmail.com Thu May 6 19:51:59 2010 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id D007763335A for ; Thu, 6 May 2010 16:52:11 -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 53193-06 for ; Thu, 6 May 2010 19:52:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by mail.postgresql.org (Postfix) with ESMTP id CD53E6338F6 for ; Thu, 6 May 2010 16:52:00 -0300 (ADT) Received: by qyk1 with SMTP id 1so531281qyk.5 for ; Thu, 06 May 2010 12:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/U7zdF/JTF7HET0IzOUD3FhuYlHkf/9unb2+1eVd3bM=; b=LLga73RIgo5bxJYnNmaWNHaDwHlFhAP2ARFrHrXNBeShHPj8of6fmwdynZCM+sSixn uhrV+xBKw8h34ml2j/tOtd5b2ebiJioJOTedu9ZZFwZqsQKfEyA9K1lU4O+gBJ/ykbw1 Wr8jQ9SiiW5+0GkawUJ0UfNKFBe/szXQFI2yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Vn95ejIJKLdpMINu5LD+GwW7Vno33KHd/oVKz1pvO11c/uSbB2WHcMbHJUXo47EaET alN67bIOTsPY+WtMg/+Qf+9MvcAVPJRZXaWKSqtb33ytnZrMS1gX5f8/BztF8FdpQWSZ ShE0B5HrcuMHRim1ukTm1WTSlKei24CIquNQ0= MIME-Version: 1.0 Received: by 10.224.71.222 with SMTP id i30mr8120113qaj.285.1273175519492; Thu, 06 May 2010 12:51:59 -0700 (PDT) Received: by 10.229.217.134 with HTTP; Thu, 6 May 2010 12:51:59 -0700 (PDT) In-Reply-To: <4494B2D02FF5486EA4ACE2E615871EB7@VALUED92EC3B5D> References: <4494B2D02FF5486EA4ACE2E615871EB7@VALUED92EC3B5D> Date: Thu, 6 May 2010 16:51:59 -0300 Message-ID: Subject: Re: Consulta From: Mariano Reingart To: Julio Lechuga - ProSoft Cc: arpug@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.8 tagged_above=-10 required=5 tests=BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201005/3 X-Sequence-Number: 405 Sobre el tema de la capacitaci=F3n, seguimos viendo de hacer alg=FAn evento o cursos generales y/o a distancias. Quiz=E1s si hay interesados podemos ver de armar algo. Adem=E1s, podemos ver de armar algo particular. Para subscribirse a las listas: http://www.arpug.com.ar/trac/wiki/Soporte Sds Mariano Reingart http://www.arpug.com.ar http://www.sistemasagiles.com.ar http://reingart.blogspot.com 2010/5/2 Julio Lechuga - ProSoft : > > En principio estoy interesado en algun curso de PgSql > > Tambien me gustaria aderir a la lista > > > Saludos > > > Julio Lechuga > > (011)4443-4337 > > (011) 15-5003-4168 > > > > __________ Information from ESET NOD32 Antivirus, version of virus signat= ure > database 4978 (20100326) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > From elovelle@dialdata.com.ar Fri May 6 23:04:13 2011 Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id A2C991337BEA for ; Fri, 6 May 2011 20:13:26 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 37615-04 for ; Fri, 6 May 2011 23:13:19 +0000 (UTC) X-Greylist: delayed 00:08:57.782767 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 2A4701337BE4 for ; Fri, 6 May 2011 20:13:18 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id 7840C2E3A4 for ; Fri, 6 May 2011 20:04:13 -0300 (ART) Received: from SOP1.dialdata.com.ar ([192.1.2.20]) by 192.1.3.1 with HTTP (HTTP/1.1 POST); Fri, 06 May 2011 20:04:13 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_27dd9f117f135368a989a4ef21cd43c3" Date: Fri, 06 May 2011 20:04:13 -0300 From: Ezequiel Lovelle To: Arpug Subject: Consulta Organization: Teleservicios y Marketing S.A Message-ID: X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: 7840C2E3A4.AD259 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=2.507 tagged_above=-10 required=5 tests=BAYES_50=0.8, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=1.164, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: ** X-Archive-Number: 201105/1 X-Sequence-Number: 585 --=_27dd9f117f135368a989a4ef21cd43c3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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. --=_27dd9f117f135368a989a4ef21cd43c3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Buenas a todos!, les voy a hacer una pregunta, un poco genérica a= sí 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&e= acute;n los parámetros del kernel obviamente.

Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on 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 i= nserts?

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

Cualquier sugerencia me va a venir bien.

 

Gracias.

--=_27dd9f117f135368a989a4ef21cd43c3-- From fhevia@gmail.com Sat May 7 00:28:23 2011 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 1B0901337B67 for ; Fri, 6 May 2011 21:28:31 -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 09991-08 for ; Sat, 7 May 2011 00:28:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 7816A1337999 for ; Fri, 6 May 2011 21:28:23 -0300 (ADT) Received: by vxi39 with SMTP id 39so3945201vxi.19 for ; Fri, 06 May 2011 17:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e5kZ2sCwtvJkxIldNOYOH3fxJ5jFgwkTmAnopeDT5Ms=; b=BYxuqJ6Wl12EZotxc0gZsp1uIRIOV9geX+WAHC48RhZDCMURP3hi7bT7k/GJS1GsGL 2aUa1NvQ0hBqakXXK63p58DZJJ04u5TzzqJW/Yqa0pF+9L4bUnLJiWMKVUgLsuDGFZqE XjPhI324UsCTTUaSrk/1u53G+39AkCJIxezr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ETZjszZeijkWhwOn62eGUO1OuGQtsIMUW/bVopstdmAC+mo9Zq8nWSZvnTjFDqYERY pPxZ5gMEHZuks9+gWTUvzz9NSlK7F1vx/v4+UqXn27IAEZPEaS6KnQWjWkUHRLFD0dua /JYZERMGVz0zShjZPeXYaulksviyN934uMOmA= MIME-Version: 1.0 Received: by 10.52.188.70 with SMTP id fy6mr1763872vdc.55.1304728103359; Fri, 06 May 2011 17:28:23 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Fri, 6 May 2011 17:28:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2011 21:28:23 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=bcaec547c8e52114c704a2a4af8f X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.355 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: * X-Archive-Number: 201105/2 X-Sequence-Number: 586 --bcaec547c8e52114c704a2a4af8f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/6 Ezequiel Lovelle > Buenas a todos!, les voy a hacer una pregunta, un poco gen=E9rica as=ED = 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= =E9n > los par=E1metros del kernel obviamente. > > Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) co= n > php un bucle que me hace 100000 INSERTS en una tabla con 3 campos y los > valores que inserto son solo numeros autoincrementales. > > =BFCuanto seria aprox un tiempo normal para que me haga todos los inserts= ? > Ni idea. =BFCuanto te tarda actualmente? Si te interesa compartir tu script puedo ejecutarlo en mis sistemas y comparar datos. La velocidad en inserts dependen m=E1s del sistema de I/O que tengas a que = la cantidad y velocidad de tus procesadores. > Si tuviese la necesidad, =BFcomo podria hacer grandes cargas de datos? en= el > menor tiempo posible obviamente > 1. Usa copy 2. Deshabilita fsync 3. Deshabilita =EDndices y claves for=E1neas antes del insert. Saludos, Fernando. --bcaec547c8e52114c704a2a4af8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/5/6 Ezequiel Lovelle <elovelle@dialdata.com.a= r>

Buenas a todos!, les voy a hacer una pregunta, un poco gen=E9rica as=ED = 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= =E9n los par=E1metros del kernel obviamente.

Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on php un bucle que me hace 100000 INSERTS en una tabla con 3 campos y los = valores que inserto son solo numeros autoincrementales.

=BFCuanto seria aprox un tiempo normal para que me haga todos los insert= s?

Ni idea. =BFCuanto te tarda actualmente? Si t= e interesa compartir tu script puedo ejecutarlo en mis sistemas y comparar = datos.
La velocidad en inserts dependen m=E1s del sistema de I/O que tengas a= que la cantidad y velocidad de tus procesadores.
=A0

Si tuviese la necesidad, =BFcomo podria hacer grandes cargas de datos? e= n el menor tiempo posible obviamente

1. Usa copy=
2. Deshabilita fsync
3. Deshabilita =EDndices y claves= for=E1neas antes del insert.


Saludos,
Fernando.
--bcaec547c8e52114c704a2a4af8f-- From elovelle@dialdata.com.ar Sat May 7 00:38:43 2011 Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 5D24B1337999 for ; Fri, 6 May 2011 21:39: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 70101-06 for ; Sat, 7 May 2011 00:38:49 +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 BB2D11337B92 for ; Fri, 6 May 2011 21:38:48 -0300 (ADT) Received: from mailserver.dialdata.com.ar (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id D26702E3B0; Fri, 6 May 2011 21:38:43 -0300 (ART) Received: from SOP1.dialdata.com.ar ([192.1.2.20]) by mailserver.dialdata.com.ar with HTTP (HTTP/1.1 POST); Fri, 06 May 2011 21:38:43 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4041959bc10e04569d6f2d6d5a9a7a1c" Date: Fri, 06 May 2011 21:38:43 -0300 From: Ezequiel Lovelle To: Fernando Hevia Cc: Arpug Subject: Re: Consulta Organization: Teleservicios y Marketing S.A In-Reply-To: References: Message-ID: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: D26702E3B0.AE82E 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=1.343 tagged_above=-10 required=5 tests=BAYES_50=0.8, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: * X-Archive-Number: 201105/3 X-Sequence-Number: 587 --=_4041959bc10e04569d6f2d6d5a9a7a1c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 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@dialdata.com.ar --=_4041959bc10e04569d6f2d6d5a9a7a1c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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=3Dhost  port=3Dport dbname=3Ddb user=3Duser passwo= rd=3Dpass") or die ("No me conecto...");
for ( $var =3D 1; $var <= =3D 100000 ; $var++ )
{
$sql =3D "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@dialdata.com.ar>

Buenas a todos!, les voy a hacer una pregunta, un poco genérica a= sí 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&e= acute;n los parámetros del kernel obviamente.

Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on 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 i= nserts?

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 ten= gas a que la cantidad y velocidad de tus procesadores.
 

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

1. Usa copy
2. Deshabilita fsync
3. Deshabilita índices y claves foráneas antes del inser= t.
Saludos,
Fernando.
--=_4041959bc10e04569d6f2d6d5a9a7a1c-- From fhevia@gmail.com Sat May 7 18:45:58 2011 Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C8F041337C09 for ; Sat, 7 May 2011 15:46:17 -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 48709-02 for ; Sat, 7 May 2011 18:45:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 00AC91337BF3 for ; Sat, 7 May 2011 15:45:58 -0300 (ADT) Received: by vxi39 with SMTP id 39so4476790vxi.19 for ; Sat, 07 May 2011 11:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b2t7d/4Pt7iAwPL0hJ72o2sygwog6txoAaIupc59Uqw=; b=Jf/PaxAfWcDuIyvnJZ4tTKjMtwhBmJnlfAc+OfUHjIeXVR4V7woJuxUXwi5HA9vUlc fZAEHd9KM70MMTFyb5T78656c2x7gNAK5XxKJGmwoFDDQ5EJ9M1vZZvKsRCD+qFBHBVl ECrp1yxc6F9rdVc/sdB5kULnsq7Im1mp7c0bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dv6osRYLq47/o3i/VEfpQnnfRrwwXNiGQphPRY5VpqfZEyjxih+EIrK5pvfNSmHGGm UDzOL5zTkS9+1+yWcaGTn2oMY0zBmOGt55s8YY6d9dszXUaZeuuPkRPeVUXxTfzg7MBy Rx+E0kwpt/tkfKMYD+wilU0oDR4wV+ytbl+HE= MIME-Version: 1.0 Received: by 10.52.100.70 with SMTP id ew6mr1855176vdb.95.1304793958517; Sat, 07 May 2011 11:45:58 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Sat, 7 May 2011 11:45:58 -0700 (PDT) In-Reply-To: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> Date: Sat, 7 May 2011 15:45:58 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=20cf3071c6d2670db104a2b4049e X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.355 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: * X-Archive-Number: 201105/4 X-Sequence-Number: 588 --20cf3071c6d2670db104a2b4049e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Este fue mi tiempo: $ time php test.php real 0m42.020s user 0m1.604s sys 0m1.448s Como notar=E1s, le llev=F3 1.6 seg de CPU, los otros 40 segundos se la pas= =F3 esperando a los discos. Este sistema tiene 2 cores de 1.86Ghz y dos discos SATA 7200 en RAID 1. En I/O pr=E1cticamente id=E9ntico al tuyo. Si est=E1s en 10 minutos, evidentemente ten=E9s otro problema, posiblemente= un lock sobre la tabla. Solo para que compares la enorme diferencia en tiempos que puede haber entr= e un m=E9todo y otro, fijate lo que tard=F3 esta operaci=F3n que genera exact= amente el mismo resultado: pgbench=3D# \timing Timing is on. pgbench=3D# 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=E1s ineficiente que existe. Por ah=ED si detallas mejor cu=E1l es el objetivo te podemos dar algunas ideas sobre com= o hacerlo m=E1s 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=3Dhost port=3Dport dbname=3Ddb user=3Duser password=3Dp= ass") or die > ("No me conecto..."); > for ( $var =3D 1; $var <=3D 100000 ; $var++ ) > { > $sql =3D "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 > >> Buenas a todos!, les voy a hacer una pregunta, un poco gen=E9rica as=ED= 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 tamb= i=E9n >> los par=E1metros del kernel obviamente. >> >> Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on >> php un bucle que me hace 100000 INSERTS en una tabla con 3 campos y los >> valores que inserto son solo numeros autoincrementales. >> >> =BFCuanto seria aprox un tiempo normal para que me haga todos los insert= s? >> > Ni idea. =BFCuanto te tarda actualmente? Si te interesa compartir tu scri= pt > puedo ejecutarlo en mis sistemas y comparar datos. > La velocidad en inserts dependen m=E1s del sistema de I/O que tengas a qu= e la > cantidad y velocidad de tus procesadores. > > >> Si tuviese la necesidad, =BFcomo podria hacer grandes cargas de datos? = en >> el menor tiempo posible obviamente >> > 1. Usa copy > 2. Deshabilita fsync > 3. Deshabilita =EDndices y claves for=E1neas antes del insert. > Saludos, > Fernando. > > --20cf3071c6d2670db104a2b4049e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Este fue mi tiempo:

$ time php test.php<= /div>

real =A0 =A00m42.020s
user =A0 =A00m1.60= 4s
sys =A0 =A0 0m1.448s

Como notar= =E1s, le llev=F3 1.6 seg de CPU, los otros 40 segundos se la pas=F3 esperan= do a los discos.
Este sistema tiene 2 cores de 1.86Ghz y dos discos SATA 7200 en RAID 1= . En I/O pr=E1cticamente id=E9ntico al tuyo.=A0
Si est=E1s en 10 = minutos, evidentemente ten=E9s otro problema, posiblemente un lock sobre la= tabla.

Solo para que compares la enorme diferencia en tiempos = que puede haber entre un m=E9todo y otro, fijate lo que tard=F3 esta operac= i=F3n que genera exactamente el mismo resultado:

<= div> pgbench=3D# \timing
Timing is on.
pgbench=3D# insert in= to temporal select generate_series(1, 100000),generate_series(1, 100000),ge= nerate_series(1, 100000),generate_series(1, 100000),generate_series(1, 1000= 00);
INSERT 0 100000
Time: 1089.893 ms

=

Los 100 mil inserts es la manera m=E1s ineficiente que = existe. Por ah=ED si detallas mejor cu=E1l es el objetivo te podemos dar al= gunas ideas sobre como hacerlo m=E1s eficiente.

Saludos,
Fernando.

<= br>
2011/5/6 Ezequiel Lovelle <elovelle@dialdata.com.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=3Dhost=A0 port=3Dport dbname=3Ddb user=3Duser pass= word=3Dpass") or die ("No me conecto...");
for ( $var =3D= 1; $var <=3D 100000 ; $var++ )
{
$sql =3D "INSERT INTO serve= r (aa, bb, cc, dd, ee) VALUES ('$var','$var','$var'= ,'$var','$var')";
pg_query($sql);
}
?>

Los discos son 2 Caviar Black en RAID 1

Sludos.


--20cf3071c6d2670db104a2b4049e-- From elovelle@dialdata.com.ar Sat May 7 19:38:35 2011 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 67CF61337BB4 for ; Sat, 7 May 2011 16:38:49 -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 43009-04 for ; Sat, 7 May 2011 19:38:41 +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 5AFC91337990 for ; Sat, 7 May 2011 16:38:41 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id E0FDC2E1CF; Sat, 7 May 2011 16:38:35 -0300 (ART) Received: from [192.1.3.192] by 192.1.3.1 with HTTP (HTTP/1.1 POST); Sat, 07 May 2011 16:38:35 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f60f50476ea18a0109a3ca4e7466ced0" Date: Sat, 07 May 2011 16:38:35 -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> Message-ID: <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: E0FDC2E1CF.A0449 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=4.315 tagged_above=-10 required=5 tests=BAYES_50=0.8, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=1.808, RCVD_NUMERIC_HELO=1.164, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: **** X-Archive-Number: 201105/5 X-Sequence-Number: 589 --=_f60f50476ea18a0109a3ca4e7466ced0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@dialdata.com.ar [2] mailto:elovelle@dialdata.com.ar --=_f60f50476ea18a0109a3ca4e7466ced0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Gracias por tu respuesta, se que no es una manera eficien= te pero es que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duración est&Atil= de;¡ activado.
bbdd=3D> INSERT INTO tabla (aa, bb, cc, d= d, ee) VALUES (generate_series(1, 100000),generate_series(1, 100000),genera= te_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. (des= taco 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= =2E

El problema es cuando lo hago con php desde un webserver, me tarda = lo siguiente:

#time php script.php

real    22m21.733s
user    0m1.846ssys     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= =2E

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 segu= ndos se la pasó esperando a los discos.
Este sistema tiene 2 cores de 1.86Ghz y dos discos SATA 7200 en RAID 1= =2E En I/O prácticamente idéntico al tuyo. 
Si estás en 10 minutos, evidentemente tenés otro problem= a, 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&oac= ute;n que genera exactamente el mismo resultado:
pgbench=3D# \timing
Timing is on.
pgbench=3D# insert into temporal select generate_series(1, 100000),gen= erate_series(1, 100000),generate_series(1, 100000),generate_series(1, 10000= 0),generate_series(1, 100000);
INSERT 0 100000
Time: 1089.893 ms
Los 100 mil inserts es la manera más ineficiente que existe. Po= r ahí si detallas mejor cuál es el objetivo te podemos dar al= gunas ideas sobre como hacerlo más eficiente.
Saludos,
Fernando.


2011/5/6 Ezequiel Lovelle <elovelle@dialdata.com.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:

pg_connect("host=3Dhost  port=3Dport dbname=3Ddb user=3Duser passwo= rd=3Dpass") or die ("No me conecto...");
for ( $var =3D 1; $var <= =3D 100000 ; $var++ )
{
$sql =3D "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@dialdata.com.ar>

Buenas a todos!, les voy a hacer una pregunta, un poco genérica a= sí 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&e= acute;n los parámetros del kernel obviamente.

Mi pregunta es la siguiente: Estoy haciendo (desde un servidor apache) c= on 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 i= nserts?

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 ten= gas a que la cantidad y velocidad de tus procesadores.
 

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

1. Usa copy
2. Deshabilita fsync
3. Deshabilita índices y claves foráneas antes del inser= t.
Saludos,
Fernando.

 

--=_f60f50476ea18a0109a3ca4e7466ced0-- From fhevia@gmail.com Sat May 7 20:09:59 2011 Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 0598C1337B67 for ; Sat, 7 May 2011 17:10:18 -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 17248-10 for ; Sat, 7 May 2011 20:09:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 992561337B97 for ; Sat, 7 May 2011 17:09:59 -0300 (ADT) Received: by vxi39 with SMTP id 39so4515922vxi.19 for ; Sat, 07 May 2011 13:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YAiWjS4bEsUg8EzZR33i5jyXTZPYWO1O/kdXPFfwxpM=; b=l0SH3iZA/D34F3C3qSF0pNvm30BRK2gQJwVBWUd1DWOwZ+4bYFrWqKK2lehFApLdhn dOaf6obS3+ZBOIB4Vfm+dJfm06vmUrWxMK8+Ry6auypj6CikGsP8oc9VrIj40cZoxVs/ P1xGC3AdRgC31hEs2uHrFTyDGvD0eG6ssVQBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HxK0bJBt+tycw959GVFHK1wCOLqvQx3fCYf7fMEj71BZz6iOPMmhvJG4PTZM61EMUK Bzzr64ZdVKOhBGoHDewtVm4wm3v/zEe64RvVlyTWRE6l4KnN9Y8trWwwS4MVD3uF5eH+ O6FDVyaBrrhutvoOaMADC8ULTfE71LspLmwyU= MIME-Version: 1.0 Received: by 10.52.186.231 with SMTP id fn7mr2446176vdc.255.1304798999473; Sat, 07 May 2011 13:09:59 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Sat, 7 May 2011 13:09:59 -0700 (PDT) In-Reply-To: <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> Date: Sat, 7 May 2011 17:09:59 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=bcaec547ca0fddeefa04a2b530e0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.803 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201105/6 X-Sequence-Number: 590 --bcaec547ca0fddeefa04a2b530e0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 siguient= e: > > bbdd=3D> \timing > El despliegue de duraci=C3=B3n est=C3=A1 activado. > bbdd=3D> 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=C3=B3n: 1486,699 ms > > Ah=ED veo que me funciono perfecto, me ganas por unos ms jeje. (destaco q= ue > en realidad esto es todo detr=E1s 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 d= e > php en el webserver... cosa que me parace muy rara. Igualmente voy a hac= er > el mismo script en bash o perl aver si es un problema de php. > 22 minutos es una barbaridad. Habilit=E1 log_checkpoints y log_lock_waits en postgres.conf. Fijate que dicen los logs de postgres mientras ejecut=E1s los inserts. Y corr=E9 un* vmstat 1* en el server de la base mientras ejecut=E1s el scri= pt. Alguna pista tiene que salir de esto. Slds., Fernando. > > --bcaec547ca0fddeefa04a2b530e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/5/7 Ezequiel Lovelle <elovelle@dialdata.com.a= r>

Gracias por tu respuesta, se que no=A0es=A0una manera=A0eficiente pero e= s que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duraci=C3=B3n est=C3=A1 activado= .
bbdd=3D> INSERT INTO=A0tabla (aa, bb, cc, dd, ee) VALUES (generate_= series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),gen= erate_series(1, 100000),generate_series(1, 100000));
INSERT 0 100000
Duraci=C3=B3n: 1486,699 ms

Ah=ED veo que me funciono perfecto, me ganas por unos ms jeje. (destaco = que en realidad esto es todo detr=E1s de un pgpool conectado=A0con 3 nodos,= no a una bbdd postgres directa) Pero el resultado fue bueno.

El problema es cuando lo hago con php desde un webserver,=A0me tarda lo = siguiente:

#time php script.php

real=A0=A0=A0 22m21.733s
user=A0=A0=A0 0m1.846s
sys=A0=A0=A0=A0 0m= 1.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=A0 a = hacer el mismo script en bash o perl=A0aver si es un problema de php.

22 minutos es una barbaridad.=A0

Habilit=E1 log_checkpoints y log_lock_waits en postgres.conf.
Fi= jate que dicen los logs de postgres mientras ejecut=E1s los inserts.=A0

Y corr=E9 un vmstat 1 en el server de la base mientra= s ejecut=E1s el script.

Alguna pista tiene que sal= ir de esto.

Slds.,
Fernando.

=A0

--bcaec547ca0fddeefa04a2b530e0-- From elovelle@dialdata.com.ar Sat May 7 21:27:01 2011 Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id DE55E1337B92 for ; Sat, 7 May 2011 18:27:41 -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 10691-01-6 for ; Sat, 7 May 2011 21:27:23 +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 8D4811337C23 for ; Sat, 7 May 2011 18:27:06 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id B905B2E1CF; Sat, 7 May 2011 18:27:01 -0300 (ART) Received: from [192.1.3.192] by 192.1.3.1 with HTTP (HTTP/1.1 POST); Sat, 07 May 2011 18:27:01 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_feeeb92e16bcff79d28f22cf9bb93422" Date: Sat, 07 May 2011 18:27:01 -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> Message-ID: <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: B905B2E1CF.AD656 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=3.763 tagged_above=-10 required=5 tests=BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=1.808, RCVD_NUMERIC_HELO=1.164, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: *** X-Archive-Number: 201105/7 X-Sequence-Number: 591 --=_feeeb92e16bcff79d28f22cf9bb93422 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@dialdata.com.ar --=_feeeb92e16bcff79d28f22cf9bb93422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Puse fsync =3D off

#time php script.php

real    0m50.592s
user    0m1.744ssys     0m1.243s

Mejoro bastante, en cuanto pueda te paso lo de los logs, ¿al= guna 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@dialdata.com.ar>

Gracias por tu respuesta, se que no es una manera eficien= te pero es que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duración est&Atil= de;¡ activado.
bbdd=3D> INSERT INTO tabla (aa, bb, cc, d= d, ee) VALUES (generate_series(1, 100000),generate_series(1, 100000),genera= te_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. (des= taco 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= =2E

El problema es cuando lo hago con php desde un webserver, me tarda = lo siguiente:

#time php script.php

real    22m21.733s
user    0m1.846ssys     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= =2E

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 ins= erts. 
Y corré unvmstat 1en el server de la base mien= tras ejecutás el script.
Alguna pista tiene que salir de esto.
Slds.,
Fernando.

 

 

--=_feeeb92e16bcff79d28f22cf9bb93422-- From fhevia@gmail.com Sat May 7 22:40:37 2011 Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 828BB1337BD2 for ; Sat, 7 May 2011 19:40:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 66100-04 for ; Sat, 7 May 2011 22:40:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 1856E1337BCC for ; Sat, 7 May 2011 19:40:36 -0300 (ADT) Received: by vxi39 with SMTP id 39so4579632vxi.19 for ; Sat, 07 May 2011 15:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=E5xBhpZ4uFkzYXTYBYW8Qx2yFEW+9rjpPQrXLSz6ynU=; b=DSSgbfjjm3RgosWGJeT+auqEVUWT3r6LBCa4XoPBVuOXN2E6jfdEF+pJqbOf7R0yRf NXLpjEL6SpxfdjNLIurVTzwcd6uMmjR8TBtyuwK2DM/K4ifOFkIVx8On6MH88FsOuCcX HnL1finsh6hBEPhXp8qu/y1JywxZ4Q3pgBHlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oci3Yuq5rQUd41UzBM3dU46WsfRsafZxZ+mknPmx25uT9vvpO3OalAP2Jf1arLxP/6 qkLFc9565hQtBgjyStMTIUjCNkGoLP/pym10Mepywz2X0W4D7rltEmmghP0JKAIuw3hX MpWw3cbI/+PN0yF+Z+m+MqpbblqXyADi3rHEU= MIME-Version: 1.0 Received: by 10.52.97.227 with SMTP id ed3mr1153964vdb.295.1304808037055; Sat, 07 May 2011 15:40:37 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Sat, 7 May 2011 15:40:37 -0700 (PDT) In-Reply-To: <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> Date: Sat, 7 May 2011 19:40:37 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=20cf307abeed8c7c2204a2b74ba2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.803 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201105/8 X-Sequence-Number: 592 --20cf307abeed8c7c2204a2b74ba2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ojo: Deshabilitar fsync aplica =FAnicamente en casos muy especiales, como l= a restauraci=F3n inicial de una base de datos. Es un modo de operaci=F3n inse= gura y puede provocar corrupci=F3n en la base si hay un crash o corte de luz. Los tiempos que te pas=E9 son con fsync =3D on. Fijate los logs y vmstat que te arrojan con fsync =3Don mientras corres el test. 2011/5/7 Ezequiel Lovelle > Puse fsync =3D 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, =BFalguna idea d= e > alg=FAn otro par=E1metro 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=3D> \timing >> El despliegue de duraci=C3=B3n est=C3=A1 activado. >> bbdd=3D> 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=C3=B3n: 1486,699 ms >> >> Ah=ED veo que me funciono perfecto, me ganas por unos ms jeje. (destaco = que >> en realidad esto es todo detr=E1s 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 ha= cer >> el mismo script en bash o perl aver si es un problema de php. >> > 22 minutos es una barbaridad. > Habilit=E1 log_checkpoints y log_lock_waits en postgres.conf. > Fijate que dicen los logs de postgres mientras ejecut=E1s los inserts. > Y corr=E9 un*vmstat 1*en el server de la base mientras ejecut=E1s el scr= ipt. > Alguna pista tiene que salir de esto. > Slds., > Fernando. > >> >> > > --20cf307abeed8c7c2204a2b74ba2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ojo: Deshabilitar fsync aplica =FAnicamente en casos muy especiales, como l= a restauraci=F3n inicial de una base de datos. Es un modo de operaci=F3n in= segura y puede provocar corrupci=F3n en la base si hay un crash o corte de = luz.

Los tiempos que te pas=E9 son con fsync =3D on.
Fijate los logs y vmstat que te arrojan con fsync =3Don mientr= as corres el test.


2011/5/7 Ez= equiel Lovelle <elovelle@dialdata.com.ar>

Puse fsync =3D off

#time php script.php

real=A0=A0=A0 0m50.592s
user=A0=A0=A0 0m1.744s
sys=A0=A0=A0=A0 0m1= .243s

Mejoro bastante, en cuanto pueda te paso=A0lo de los logs, =BFalguna ide= a de alg=FAn otro par=E1metro para tocar?

On Sat, 7 May 2011 17:09:59 -0300, Fernando Hevia wrote:

=A0



2011/5/7 Ezequ= iel Lovelle <elovelle@dialdata.com.ar>

Gracias por tu respuesta, se que no=A0es=A0una manera=A0eficiente pero e= s que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duraci=C3=B3n est=C3=A1 activado= .
bbdd=3D> INSERT INTO=A0tabla (aa, bb, cc, dd, ee) VALUES (generate_= series(1, 100000),generate_series(1, 100000),generate_series(1, 100000),gen= erate_series(1, 100000),generate_series(1, 100000));
INSERT 0 100000
Duraci=C3=B3n: 1486,699 ms

Ah=ED veo que me funciono perfecto, me ganas por unos ms jeje. (destaco = que en realidad esto es todo detr=E1s de un pgpool conectado=A0con 3 nodos,= no a una bbdd postgres directa) Pero el resultado fue bueno.

El problema es cuando lo hago con php desde un webserver,=A0me tarda lo = siguiente:

#time php script.php

real=A0=A0=A0 22m21.733s
user=A0=A0=A0 0m1.846s
sys=A0=A0=A0=A0 0m= 1.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=A0 a = hacer el mismo script en bash o perl=A0aver si es un problema de php.

22 minutos es una barbaridad.=A0
Habilit=E1 log_checkpoints y log_lock_waits en postgres.conf.
Fijate que dicen los logs de postgres mientras ejecut=E1s los inserts.= =A0
Y corr=E9 unvmstat 1en el server de la ba= se mientras ejecut=E1s el script.
Alguna pista tiene que salir de esto.
Slds.,
Fernando.

=A0

=A0


--20cf307abeed8c7c2204a2b74ba2-- From elovelle@dialdata.com.ar Sat May 7 23:46:32 2011 Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C92A91337990 for ; Sat, 7 May 2011 20:46:49 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 10841-04 for ; Sat, 7 May 2011 23:46:41 +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 6D6D2133655C for ; Sat, 7 May 2011 20:46:39 -0300 (ADT) Received: from mailserver.dialdata.com.ar (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id 0FDB52E1CF; Sat, 7 May 2011 20:46:33 -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 20:46:32 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_07484997ecc6d97e6fc994314a87b521" Date: Sat, 07 May 2011 20:46:32 -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> Message-ID: <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: 0FDB52E1CF.A4DAC 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/9 X-Sequence-Number: 593 --=_07484997ecc6d97e6fc994314a87b521 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@dialdata.com.ar [2] mailto:elovelle@dialdata.com.ar --=_07484997ecc6d97e6fc994314a87b521 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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  re=   pi  po    fr  sr ad4 ad6   in&nbs= p;  sy   cs us sy id
 0 0 0   2336M = ; 7457M     2   0   0   0=      0   0 356 356 1260 3185 10173  1&nb= sp; 1 98
 0 0 0   2336M  7457M   &n= bsp; 2   0   0   0     0&= nbsp;  0 435 435 1515 3853 12193  1  1 98
 0 0 0&n= bsp;  2336M  7457M     3   0 &= nbsp; 0   0     0   0 531 532 1843 = 4668 14781  0  1 98
 0 0 0   2336M  7457= M     4   0   0   0 =     0   0 751 752 2605 6544 20742  1  1 = 98
 0 0 0   2336M  7457M     4=    0   0   0     0 &= nbsp; 0 925 923 3238 7997 25565  1  2 98
 0 0 0 &n= bsp; 2336M  7457M     3   0   = 0   0     0   0 627 628 2183 5503 1= 7403  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   2= 336M  7456M     4   0   0 = ;  0     0   0 681 683 2382 5964 18988&n= bsp; 1  2 98
 0 0 0   2336M  7456M  = ;   3   0   0   0   =   0   0 628 628 2180 5491 17401  0  2 98
&nbs= p;0 0 0   2336M  7456M     2  = 0   0   0     0   0 545 = 544 1906 4787 15182  0  1 99
 0 0 0   2336M&n= bsp; 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&nbs= p;  0   0     0   0 405 403 14= 09 3596 11401  0  1 98
 0 0 0   2336M  7= 456M    41   0   0   0 &n= bsp;   0   0 222 224  790 2078 6525  0  = 0 100
 0 0 0   2336M  7456M    = ; 3   0   0   0     0&nbs= p;  0 693 693 2403 6102 19174  1  1 98
 0 0 0 = ;  2336M  7456M     5   0 &nbs= p; 0   0     0   0 828 827 2910 722= 8 23070  1  2 97
 0 0 0   2336M  7456M&n= bsp;    3   0   0   0 &nb= sp;   4   0 715 716 2486 6238 19804  1  3 97<= br /> 0 0 0   2336M  7456M     4&nb= sp;  0   0   0     0 &nbs= p; 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&n= bsp;  0   0   0     8 &nb= sp; 0 598 598 2067 5180 16650  1  1 98
 0 0 0 &nbs= p; 2336M  7455M     3   0   0&= nbsp;  0     0   0 667 667 2316 5865 184= 98  1  1 98
 0 0 0   2336M  7455M &= nbsp;   6   0   0   0  &n= bsp;  0   0 880 879 3048 7688 24303  1  2 97
=  0 0 0   2336M  7455M    27   = 0   0   0     0   0 758 7= 59 2608 6650 20957  1  1 98
 0 0 0   2336M&nb= sp; 7455M     4   0   0  = 0     6   0 715 713 2457 6154 19698  1&= nbsp; 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 41= 0 1442 3660 11588  1  1 98
 0 0 0   2336M&nbs= p; 7455M     3   0   0   = 0     0   0 492 494 1712 4333 13768  1&n= bsp; 1 98
 0 0 0   2336M  7455M   &= nbsp; 1   0   0   0     0=    0 330 330 1167 2946 9470  0  1 98
 0 0 0&n= bsp;  2336M  7455M     3   0 &= nbsp; 0   0     0   0 410 410 1441 = 3657 11561  0  1 99
 0 0 0   2336M  7455= M     3   0   0   0 =     0   0 692 691 2401 6043 19114  0  1 = 98
 1 0 0   2336M  7455M     4=    0   0   0     0 &= nbsp; 0 726 726 2526 6316 20039  1  1 98
 0 0 0 &n= bsp; 2336M  7455M     3   0   = 0   0     0   0 686 687 2393 5999 1= 9103  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   2= 336M  7454M     4   0   0 = ;  0     4   0 718 719 2479 6240 19789&n= bsp; 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&nb= sp;  0   0     0   0 746 744 2= 587 6540 20625  1  2 98
 0 0 0   2336M  = 7454M     8   0   0   0&n= bsp;    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
&nb= sp;0 0 0   2328M  7455M     0  = ; 0   0   0     0   0&nbs= p;  0   0   10  171  456  0  0= 100
 0 0 0   2363M  7454M   414 &n= bsp; 0   0   0   161   0  = ; 4   4   33 6478  601  2  0 98
&nb= sp;0 0 0   2363M  7454M     0  = ; 0   0   0     0   0&nbs= p;  0   0    7  151  456  0&nb= sp; 0 100
 0 0 0   2363M  7454M   &= nbsp; 0   0   0   0     0=    0   0   0   18  149  5= 75  0  0 100
 0 0 0   2363M  7454M =     0   0   0   0  &= nbsp;  0   0   3   3   10 = ; 147  485  0  0 100
 0 0 0   2363M = ; 7454M     0   0   0   0=      0   0   0   0 &= nbsp;  6  149  465  0  0 100
 0 0 0 = ;  2363M  7454M     2   0 &nbs= p; 0   0     0   0   0&nb= sp;  0    7  152  489  0  0 100
 0 0 0   2363M  7454M     0 =   0   0   0     4   = 0   2   2   24  149  604  0&nb= sp; 0 100
 0 0 0   2363M  7454M   &= nbsp; 0   0   0   0     8=    0   9   9   22  147  5= 62  0  0 100


LOGS


May  7 20:40:54 pgsql1 postgres[2024] [99998-1] LOG:  st= atement: INSERT INTO tabla (aa, bb, cc, dd, ee) VALUES ('99997
','9999= 7','99997','99997','99997')
May  7 20:40:54 pgsql1 postgres[2024]= [99999-1] LOG:  statement: INSERT INTO tabla (aa, bb, cc, dd, ee) VAL= UES ('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:  sta= tement: INSERT INTO tabla (aa, bb, cc, dd, ee) VALUES ('1000
00','1000= 00','100000','100000','100000')
May  7 20:41:52 pgsql1 postgres[1= 954] [5-1] LOG:  checkpoint starting: time
May  7 20:44:32 p= gsql1 postgres[1954] [6-1] LOG:  checkpoint complete: wrote 799 buffer= s (0.3%); 0 transaction log file(s) added, 0 removed, 0 recycled; write
=3D160.550 s, sync=3D0.008 s, total=3D160.562 s

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

Saludo= s

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 o= peración insegura y puede provocar corrupción en la base si h= ay un crash o corte de luz.

Los tiempos que te pasé son con fsync =3D on.
Fijate los logs y vmstat que te arrojan con fsync =3Don mientras corre= s el test.


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

Puse fsync =3D off

#time php script.php

real    0m50.592s
user    0m1.744ssys     0m1.243s

Mejoro bastante, en cuanto pueda te paso lo de los logs, ¿al= guna 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@dialdata.com.ar>

Gracias por tu respuesta, se que no es una manera eficien= te pero es que quiero testear la bbdd en todos los aspectos.

Te comento, cuando lo hago desde la consola de postgres me da lo siguien= te:

bbdd=3D> \timing
El despliegue de duración est&Atil= de;¡ activado.
bbdd=3D> INSERT INTO tabla (aa, bb, cc, d= d, ee) VALUES (generate_series(1, 100000),generate_series(1, 100000),genera= te_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. (des= taco 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= =2E

El problema es cuando lo hago con php desde un webserver, me tarda = lo siguiente:

#time php script.php

real    22m21.733s
user    0m1.846ssys     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= =2E

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 ins= erts. 
Y corré unvmstat 1en el server de la base mien= tras ejecutás el script.
Alguna pista tiene que salir de esto.
Slds.,
Fernando.

 

 

--=_07484997ecc6d97e6fc994314a87b521-- From fhevia@gmail.com Sun May 8 00:02:53 2011 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 7CBA81337990 for ; Sat, 7 May 2011 21:03:01 -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 75498-07 for ; Sun, 8 May 2011 00:02:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 26EAB133655C for ; Sat, 7 May 2011 21:02:53 -0300 (ADT) Received: by vxi39 with SMTP id 39so4610304vxi.19 for ; Sat, 07 May 2011 17:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CmLvB19ZWjZuestP8Md25tU8m0/GTIZ86EVhgDFQf6Y=; b=kBQ0d8GwACT1rkGWfJdvEVYsC3blu5QDjFAoTv5MulniwpJlkkrSiU5uiWredKqeB0 LZnymahjInkFx0dWbaDXdYYZCDFDplixZ1LHcKH+24LyC8Q2c3jqL205B1MvcOV7JVtX gUAgV/4INgwsgy0wqEkX5fV6B0Zo9fb9Z9nzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v2DptuWCrztK8rF3rra6B8HZDWP/WXjlY1T/N8/HXs8fZShXYKBOxg0uXmP5WGzm/j LNtcTw9PKD/+wr+2r5YTV7LRpQuRWT/MSZfOwSqFWPkIdkFieKC5DmGjJohay9iL+Blv JAwUCxWjUPFAzze0cvXdm2frA79Czf++DueW0= MIME-Version: 1.0 Received: by 10.52.113.138 with SMTP id iy10mr166118vdb.55.1304812973236; Sat, 07 May 2011 17:02:53 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Sat, 7 May 2011 17:02:53 -0700 (PDT) In-Reply-To: <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> Date: Sat, 7 May 2011 21:02:53 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=bcaec54865d2c4a0b004a2b8712c X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.803 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201105/10 X-Sequence-Number: 594 --bcaec54865d2c4a0b004a2b8712c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/7 Ezequiel Lovelle > Ok, con fsync=3Don 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 =FAltimos registros, a partir del que pint=E9 en rojo, me da la impresi=F3n que el script termin=F3 de ejecutar. Sin embargo, la ocupaci=F3= n de discos sigue al 100%. Indicar=EDa que ten=E9s algo m=E1s ejecutando que te est=E1 ocupando todo e= l ancho de banda de I/O. --bcaec54865d2c4a0b004a2b8712c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxMS81LzcgRXplcXVpZWwgTG92ZWxs ZSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzplbG92ZWxsZUBkaWFsZGF0YS5j b20uYXIiPmVsb3ZlbGxlQGRpYWxkYXRhLmNvbS5hcjwvYT4mZ3Q7PC9zcGFuPjxicj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+Cgo8ZGl2Pgo8cD5PaywgY29u IGZzeW5jPW9uIGRpcmVjdGFtZW50ZSBhIHBvc3RncmVzIG1lIHRhcmRvOjxicj48YnI+PGJyPiN0 aW1lIHBocCBzY3JpcHQucGhwPGJyPnJlYWygoKAgNW0zNC40NzFzPGJyPnVzZXKgoKAgMG0yLjUy N3M8YnI+c3lzoKCgoCAwbTEuOTE3czxicj48YnI+oHByb2NzoKCgoKAgbWVtb3J5oKCgoKAgcGFn ZaCgoKCgoKCgoKCgoKCgoKCgoKAgZGlza3OgoKCgIGZhdWx0c6CgoKCgoKCgIGNwdTxicj4KoHIg YiB3oKCgoCBhdm2goKAgZnJloKAgZmx0oCByZaAgcGmgIHBvoKCgIGZyoCBzciBhZDQgYWQ2oKAg aW6goCBzeaCgIGNzIHVzIHN5IGlkPGJyPqAuLi48YnI+oDAgMCAwoKAgMjMzNk2gIDc0NTRNoKCg oCA4oKAgMKCgIDCgoCAwoKCgoCAwoKAgMCA4MTAgODEwIDI4NDQgNzExNCAyMjQ1NqAgMaAgMiA5 Nzxicj6gMCAwIDCgoCAyMzM2TaAgNzQ1NE2goCA2MzKgoCAwoKAgMKCgIDCgoCA2NDmgoCAwIDQ5 NiA0OTcgMTc0MiA0NTc3IDEzOTU3oCAwoCAxIDk5PGJyPgqgMCAwIDCgoCAyMzI4TaAgNzQ1NU2g oCAyNjWgoCAwoKAgMKCgIDCgoCA2NjKgoCAwIDE4OSAxODmgIDY3NyAxNzk1IDU2OTagIDCgIDAg OTk8YnI+oDxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iI2ZmMDAwMCI+MCAw IDCgoCAyMzI4TaAgNzQ1NU2goKCgIDCgoCAwoKAgMKCgIDCgoKCgIDCgoCAwoKAgMKCgIDCgoCAx MKAgMTcxoCA0NTagIDCgIDAgMTAwPC9mb250Pjxicj4KoDAgMCAwoKAgMjM2M02gIDc0NTRNoKAg NDE0oKAgMKCgIDCgoCAwoKAgMTYxoKAgMKCgIDSgoCA0oKAgMzMgNjQ3OKAgNjAxoCAyoCAwIDk4 PGJyPqAwIDAgMKCgIDIzNjNNoCA3NDU0TaCgoKAgMKCgIDCgoCAwoKAgMKCgoKAgMKCgIDCgoCAw oKAgMKCgoCA3oCAxNTGgIDQ1NqAgMKAgMCAxMDA8YnI+oDAgMCAwoKAgMjM2M02gIDc0NTRNoKCg oCAwoKAgMKCgIDCgoCAwoKCgoCAwoKAgMKCgIDCgoCAwoKAgMTigIDE0OaAgNTc1oCAwoCAwIDEw MDxicj4KoDAgMCAwoKAgMjM2M02gIDc0NTRNoKCgoCAwoKAgMKCgIDCgoCAwoKCgoCAwoKAgMKCg IDOgoCAzoKAgMTCgIDE0N6AgNDg1oCAwoCAwIDEwMDxicj6gMCAwIDCgoCAyMzYzTaAgNzQ1NE2g oKCgIDCgoCAwoKAgMKCgIDCgoKCgIDCgoCAwoKAgMKCgIDCgoKAgNqAgMTQ5oCA0NjWgIDCgIDAg MTAwPGJyPqAwIDAgMKCgIDIzNjNNoCA3NDU0TaCgoKAgMqCgIDCgoCAwoKAgMKCgoKAgMKCgIDCg oCAwoKAgMKCgoCA3oCAxNTKgIDQ4OaAgMKAgMCAxMDA8YnI+CqAwIDAgMKCgIDIzNjNNoCA3NDU0 TaCgoKAgMKCgIDCgoCAwoKAgMKCgoKAgNKCgIDCgoCAyoKAgMqCgIDI0oCAxNDmgIDYwNKAgMKAg MCAxMDA8YnI+oDAgMCAwoKAgMjM2M02gIDc0NTRNoKCgoCAwoKAgMKCgIDCgoCAwoKCgoCA4oKAg MKCgIDmgoCA5oKAgMjKgIDE0N6AgNTYyoCAwoCAwIDEwMDxicj48YnI+PC9wPjwvZGl2PjwvYmxv Y2txdW90ZT48ZGl2PkVuIGVzdG9zIPpsdGltb3MgcmVnaXN0cm9zLCBhIHBhcnRpciBkZWwgcXVl IHBpbnTpIGVuIHJvam8sIG1lIGRhIGxhIGltcHJlc2nzbiBxdWUgZWwgc2NyaXB0IHRlcm1pbvMg ZGUgZWplY3V0YXIuIFNpbiBlbWJhcmdvLCBsYSBvY3VwYWNp824gZGUgZGlzY29zIHNpZ3VlIGFs IDEwMCUuPC9kaXY+CjxkaXY+SW5kaWNhcu1hIHF1ZSB0ZW7pcyBhbGdvIG3hcyBlamVjdXRhbmRv IHF1ZSB0ZSBlc3ThIG9jdXBhbmRvIHRvZG8gZWwgYW5jaG8gZGUgYmFuZGEgZGUgSS9PLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pgo= --bcaec54865d2c4a0b004a2b8712c-- From elovelle@dialdata.com.ar Sun May 8 00:12:44 2011 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-- From fhevia@gmail.com Sun May 8 02:46:49 2011 Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 806A41337B92 for ; Sat, 7 May 2011 23:46:57 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 29657-08 for ; Sun, 8 May 2011 02:46:52 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id C44BF1337BA3 for ; Sat, 7 May 2011 23:46:49 -0300 (ADT) Received: by vxi39 with SMTP id 39so4666664vxi.19 for ; Sat, 07 May 2011 19:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3+dveeJ3rszgFmrHc5BrBaDN8V4wwuMhY7VTrx9BiQ0=; b=bg582Qe82aho0zaD9oKIykANHkI5Ycf/OfJ5DStWn8Bxo3rB/w0PJ2uP9t+M9EnhTo EI8EoDAOwYrYlwA404d2oj7gCg6mTzM0t9bwyadbksalrWXNh5I2xvgxreCtWwULzfAv xkYrXtpl4lcHFh73pYpIZYVd6fq7mY6CW/2/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nPbp1nJgPCNQoGXrcmvhJCRkNNwuBLQdOk5QjGdyYhKTVAw2x2QpDorFbYOiki/Szk OwpZOa3BIXasjRjPC9HK+bFX0HKCCLV35UvsM4lE3BbIM6JceO4qN+upx1DxQ39ZbX+c +uDorp25CtvCPcY6irMma5uQVChwaACPuSCmw= MIME-Version: 1.0 Received: by 10.52.94.173 with SMTP id dd13mr6325574vdb.15.1304822809826; Sat, 07 May 2011 19:46:49 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Sat, 7 May 2011 19:46:49 -0700 (PDT) In-Reply-To: <549d4022bc9e560e8a4d96f30827f0dc@dialdata.com.ar> References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> <549d4022bc9e560e8a4d96f30827f0dc@dialdata.com.ar> Date: Sat, 7 May 2011 23:46:49 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=20cf307f3420131a5704a2babc9c X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.803 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201105/12 X-Sequence-Number: 596 --20cf307f3420131a5704a2babc9c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/7 Ezequiel Lovelle > Me voy a fijar, aunque la prueba la hice en los dos postgres de los > nodos, siendo practicamente id=E9ntico 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, =BFporque cuando hago la query en la consola de > postgres me la ejecuta en cuesti=F3n de 1 segundo y escribi=F3 bien los d= atos 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 po= r 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 =3D '*' > wal_level =3D archive > fsync =3D on > archive_mode =3D on > archive_command =3D 'exit 0' > Donde estas escribiendo los archives? Deshabilita el archive_mode a ver com= o 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 sistema 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 sistema. Mantene max_connections entre 20 y 50. Mas si estas usando un connection pooler. Slds., Fernando. --20cf307f3420131a5704a2babc9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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=E9ntico 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, =BFporque cuando hago la query en la consola de = postgres me la ejecuta en cuesti=F3n de 1 segundo y escribi=F3 bien los dat= os 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 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=A0acelerar el script es ejecutar un SET LOCAL synchronous_commit TO OFF antes de hacer los in= serts.
=A0

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

listen_addresses =3D '*'
wal_level =3D archive
fsync =3D o= n
archive_mode =3D on
archive_command =3D 'exit 0'

<= /blockquote>
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.
=A0

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.
=A0
Slds.,
Fernando.
=A0
--20cf307f3420131a5704a2babc9c-- From elovelle@dialdata.com.ar Sun May 8 23:04:07 2011 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-- From fhevia@gmail.com Mon May 9 11:34:42 2011 Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id EA8D91337B97 for ; Mon, 9 May 2011 08:34:51 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 66806-09 for ; Mon, 9 May 2011 11:34:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id 4178C1337B6E for ; Mon, 9 May 2011 08:34:42 -0300 (ADT) Received: by vxi39 with SMTP id 39so5650700vxi.19 for ; Mon, 09 May 2011 04:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Od253iSsemasE7ZvI10OadEL89E5WwiMua33Y9g5gqA=; b=uv5cR7IBwS9jL6p4IR9RKFw6Tsd9/0LCB6yTrYWh7EdR0NfnPxgU+/ZWtXZ1/nh19R xs8sN/v4UzrntEc8bmnPrW1v1p44dW5lx+RUV4+dSL12MYzRyjfSYAUpsArbQYAUYoOA uYQIfcg2dXLOfXhcTBpdEwA5Ebio4OQPF04eI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c2c8aD2dzRDb6G9Te0I+d1c86lVUCAHgbZiv4dUSPYnDYaqFUzPTgN/IJtKhYkT8No IMPHVVzSFwkNtVs1D3uMyNJdCGYKvQ7+1azZABDMzo9+FE1Tp52vF9UHyhfgcLvGEEwV TxFDMag61uxjHSw8IKXl/w7nckH0LQeeCjddU= MIME-Version: 1.0 Received: by 10.52.72.67 with SMTP id b3mr1974332vdv.215.1304940882773; Mon, 09 May 2011 04:34:42 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Mon, 9 May 2011 04:34:42 -0700 (PDT) In-Reply-To: References: <7e584a1df61e628d7b16d01a27d1a9d6@dialdata.com.ar> <3c82fe28fca089df4df103ce6823b1fd@dialdata.com.ar> <589af2fcfb2678bdf4db3045f370af4b@dialdata.com.ar> <6726d28cf45b54e9d92355257775977c@dialdata.com.ar> <549d4022bc9e560e8a4d96f30827f0dc@dialdata.com.ar> Date: Mon, 9 May 2011 08:34:42 -0300 Message-ID: Subject: Re: Consulta From: Fernando Hevia To: Ezequiel Lovelle Cc: Arpug Content-Type: multipart/alternative; boundary=20cf307f3bfcc545e904a2d63985 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.355 tagged_above=-10 required=5 tests=BAYES_50=0.8, FREEMAIL_FROM=0.001, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: * X-Archive-Number: 201105/14 X-Sequence-Number: 598 --20cf307f3bfcc545e904a2d63985 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/8 Ezequiel Lovelle > El server es dedicado y no tiene nada corriendo, excepto ntp y ssh > obviamente. > Estube jugando con los par=E1metros de la config y el =FAnico que me mejo= ra los > tiempos es fsync. > Si lo pongo en off mejoro muchisimo. > > ... > > Si hago: > > [root@pgsql1 ~]# dd if=3D/dev/zero of=3D/tmp/test count=3D500000 > 500000+0 records in > 500000+0 records out > 256000000 bytes transferred in 1.938541 secs (132058083 bytes/sec) > > El sistema me escribi=F3 256 Mb en 1,9 segundos a una velocidad de escrit= ura > 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=E9s. El m=E1ximo debe rondar los 35 Mbps secuenciales. Es un cach=E9 el que te est= =E1 brindando los 125 Mbps. No conozco de freebsd y no se qu=E9 m=E1s puede estar afectando tu sistema.= En tu config no veo nada que justifique los tiempos que est=E1s experimentando= . Si bien lograste bajar de 20 a 4 min, todav=EDa me sigue pareciendo bastant= e. Y la diferencia de 1'20" en la ejecuci=F3n desde el webserver me resulta m= =E1s raro todav=EDa. Algo no est=E1 bien pero no se decirte que puede ser. Se me ocurre bloating... prob=E1 truncando la tabla y luego reintentar las pruebas a ver si te arroja mejores tiempos. Tambi=E9n te recomiendo postear en la lista pgsql-performance (en ingl=E9s)= que es espec=EDfica para este tipo de consultas. Saludos. --20cf307f3bfcc545e904a2d63985 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/5/8 Ezequiel Lovelle <elove= lle@dialdata.com.ar>

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

...

Si hago:

[root@pgsql1 ~]# dd if=3D/dev/zer= o of=3D/tmp/test count=3D500000
500000+0 records in
500000+0 records = out
256000000 bytes transferred in 1.938541 secs (132058083 bytes/sec)
El sistema me escribi=F3 256 Mb en 1,9 segundos a una velocidad de escr= itura 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=E9s. El m=E1ximo debe rondar los 35 Mbps s= ecuenciales. Es un cach=E9 el que te est=E1 brindando los 125 Mbps.
No conozco de freebsd y no se qu=E9 m=E1s puede estar afectando tu sis= tema. En tu config no veo nada que justifique los tiempos que est=E1s exper= imentando. Si bien lograste bajar de 20 a 4 min, todav=EDa me sigue parecie= ndo bastante. Y la diferencia de 1'20" en la ejecuci=F3n desde el = webserver me resulta m=E1s raro todav=EDa. Algo no est=E1 bien pero no se d= ecirte que puede ser.
Se me ocurre bloating... prob=E1 truncando la tabla y luego reintentar= las pruebas a ver si te arroja mejores tiempos.

T= ambi=E9n te recomiendo postear en la lista pgsql-performance (en ingl=E9s) = que es espec=EDfica para este tipo de consultas.

Saludos.
--20cf307f3bfcc545e904a2d63985-- From elovelle@dialdata.com.ar Mon May 9 12:41:59 2011 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 7A5381337BC8 for ; Mon, 9 May 2011 09:42:14 -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 68653-04 for ; Mon, 9 May 2011 12:42:07 +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 ADC561337B6E for ; Mon, 9 May 2011 09:42:06 -0300 (ADT) Received: from 192.1.3.1 (localhost [127.0.0.1]) by mailserver.dialdata.com.ar (Postfix) with ESMTP id 89F4F2E2C6; Mon, 9 May 2011 09:41:59 -0300 (ART) Received: from [192.1.3.192] by 192.1.3.1 with HTTP (HTTP/1.1 POST); Mon, 09 May 2011 09:41:59 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a3cebcbd21decbe1e1229ff0a426346e" Date: Mon, 09 May 2011 09:41:59 -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: <288d5b82a676c524203dfd56f2e074a5@dialdata.com.ar> X-Sender: elovelle@dialdata.com.ar User-Agent: DDM/0.5 X-DDM-MailScanner-Information: DDM X-DDM-MailScanner-ID: 89F4F2E2C6.AEA39 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=4.315 tagged_above=-10 required=5 tests=BAYES_50=0.8, FUZZY_AMBIEN=0.552, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=1.808, RCVD_NUMERIC_HELO=1.164, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: **** X-Archive-Number: 201105/15 X-Sequence-Number: 599 --=_a3cebcbd21decbe1e1229ff0a426346e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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@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@dialdata.com.ar --=_a3cebcbd21decbe1e1229ff0a426346e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Voy a probar de instalar postgres en Debian a ver que pasa, muchas gr&aa= cute;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 <elovelle@dialdata.com.ar>

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.

...

Si hago:

[root@pgsql1 ~]# dd if=3D/dev/zero of=3D/tmp/test= count=3D500000
500000+0 records in
500000+0 records out
256= 000000 bytes transferred in 1.938541 secs (132058083 bytes/sec)

= El sistema me escribió 256 Mb en 1,9 segundos a una velocidad de esc= ritura 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&ea= cute;s. El máximo debe rondar los 35 Mbps secuenciales. Es un cach&e= acute; el que te está brindando los 125 Mbps.
No conozco de freebsd y no se qué más puede estar afecta= ndo 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&iacut= e;a me sigue pareciendo bastante. Y la diferencia de 1'20" en la ejecuci&oa= cute;n desde el webserver me resulta más raro todavía. Algo n= o está bien pero no se decirte que puede ser.
Se me ocurre bloating... probá truncando la tabla y luego reint= entar 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.

 

--=_a3cebcbd21decbe1e1229ff0a426346e-- From rayolandia@hotmail.com Tue Jul 22 22:07:57 2014 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X9wNX-00029H-3A for arpug@arkaria.postgresql.org; Wed, 23 Jul 2014 13:14:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X9wNV-0000rs-92 for arpug@arkaria.postgresql.org; Wed, 23 Jul 2014 13:14:41 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X9iE6-000195-K2; Tue, 22 Jul 2014 22:08:02 +0000 Received: from bay004-omc3s2.hotmail.com ([65.54.190.140]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X9iE3-0001jw-OY; Tue, 22 Jul 2014 22:08:00 +0000 Received: from BAY178-W38 ([65.54.190.187]) by BAY004-OMC3S2.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 22 Jul 2014 15:07:57 -0700 X-TMN: [Dto3cjt4PmIr4fAQBVcAMIYo8UeGH3SW] X-Originating-Email: [rayolandia@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e4f9de24-00c3-4295-b6ab-732d8f3abfa9_" From: Tomas Moore To: "arpug@postgresql.org" , "pgsql-es-ayuda@postgresql.org" , "pgsql-es-fomento@postgresql.org" Subject: Consulta Date: Tue, 22 Jul 2014 22:07:57 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2014 22:07:57.0921 (UTC) FILETIME=[65222510:01CFA5F9] X-Pg-Spam-Score: 0.8 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: arpug Precedence: bulk Sender: arpug-owner@postgresql.org --_e4f9de24-00c3-4295-b6ab-732d8f3abfa9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hola a todos=2C trabajo en una dependencia p=FAblica que frecuentemente nec= esito hacer estad=EDsticas y registrar datos=2C siempre lo hago con planill= as de c=E1lculo pero tengo la idea de hacer algo mas seguro y pr=E1ctico=2C= donde puedo aprender sql=2C yo vivo en PergaminoAtentamente Ceferino Mu=F1oz = --_e4f9de24-00c3-4295-b6ab-732d8f3abfa9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hola a todos=2C trabajo en una d= ependencia p=FAblica que frecuentemente necesito hacer estad=EDsticas y reg= istrar datos=2C siempre lo hago con planillas de c=E1lculo pero tengo la id= ea de hacer algo mas seguro y pr=E1ctico=2C donde puedo aprender sql=2C yo = vivo en Pergamino
Atentamente

Ceferino Mu=F1oz=
= --_e4f9de24-00c3-4295-b6ab-732d8f3abfa9_-- From paul.ramirez@cnr.gob.sv Tue Oct 27 21:16:39 2015 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZrTh1-0005gl-6j for arpug@arkaria.postgresql.org; Wed, 28 Oct 2015 16:35:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZrTh0-0005Zl-Jp for arpug@arkaria.postgresql.org; Wed, 28 Oct 2015 16:35:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZrBZo-00041J-Cq for arpug@postgresql.org; Tue, 27 Oct 2015 21:14:40 +0000 Received: from gate2.cnr.gob.sv ([190.120.30.26]) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZrBZk-0007Go-2J for arpug@postgresql.org; Tue, 27 Oct 2015 21:14:37 +0000 Received: from mail.cnr.gob.sv ([192.168.4.126]) by gate2.cnr.gob.sv with ESMTP id t9RLEXMt005587-t9RLEXMu005587 for ; Tue, 27 Oct 2015 15:14:33 -0600 Received: from dtiw7pramirez [192.168.25.162] by mail.cnr.gob.sv with ESMTP (SMTPD-12.5.0.248) id ee840002b089614d; Tue, 27 Oct 2015 15:14:19 -0600 From: =?iso-8859-1?Q?Pa=FAl_Enrique_Ram=EDrez?= To: Subject: Consulta Date: Tue, 27 Oct 2015 15:16:39 -0600 Message-ID: <003f01d110fc$c53394b0$4f9abe10$@ramirez@cnr.gob.sv> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D110CA.7A9924B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEQ/MT8NZnqnzzWTvWzR69UacaIxg== Content-Language: es-sv X-Pg-Spam-Score: 1.8 (+) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: arpug Precedence: bulk Sender: arpug-owner@postgresql.org Este es un mensaje con varias partes en formato MIME. ------=_NextPart_000_0040_01D110CA.7A9924B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Buenas tardes. Trabajo para una instituci=F3n gubernamental en El Salvador. Utilizamos = bases de datos Oracle y se est=E1 evaluando la alternativa de migrar a = PostgreSQL. =20 Me gustar=EDa saber si me pueden orientar con documentos que me permitan prever cu=E1les podr=EDan ser los principales obst=E1culos que se nos = pueden presentar en dicho proceso y qu=E9 tipo de consideraciones debemos tener = m=E1s presente. =20 Gracias de antemano por su colaboraci=F3n. =20 =20 Saludos, =20 Ing. Pa=FAl Enrique Ram=EDrez Coordinador de Base de Datos Gerencia de Infraestructura Inform=E1tica Direcci=F3n de Tecnolog=EDa de la Informaci=F3n Centro Nacional de Registros paul.ramirez@cnr.gob.sv Tel=E9fono: 2593-5384=20 Celular: 7160-8439 =20 ------=_NextPart_000_0040_01D110CA.7A9924B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Buenas = tardes.

Trabajo para una = instituci=F3n gubernamental en El Salvador. =A0Utilizamos bases de datos Oracle y se = est=E1 evaluando la alternativa de migrar a PostgreSQL.

 

Me gustar=EDa saber = si me pueden orientar con documentos que me permitan prever cu=E1les podr=EDan ser = los principales obst=E1culos que se nos pueden presentar en dicho proceso y = qu=E9 tipo de consideraciones debemos tener m=E1s presente.

 

Gracias de antemano = por su colaboraci=F3n.

 

 

Saludos,

 

Ing. = Pa=FAl Enrique Ram=EDrez

Coordinador de Base de Datos

Gerencia de Infraestructura Inform=E1tica

Direcci=F3n de Tecnolog=EDa de la Informaci=F3n

Centro Nacional de Registros

paul.ramirez@cnr.gob.sv

Tel=E9fono: 2593-5384

Celular: 7160-8439

 

------=_NextPart_000_0040_01D110CA.7A9924B0-- From postgres.arg@gmail.com Thu Jul 14 17:20:16 2016 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNkJI-0004DO-9Q for arpug@arkaria.postgresql.org; Thu, 14 Jul 2016 17:20:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bNkJH-0005as-SQ for arpug@arkaria.postgresql.org; Thu, 14 Jul 2016 17:20:27 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bNkJB-0005U9-Gl for arpug@postgresql.org; Thu, 14 Jul 2016 17:20:21 +0000 Received: from mail-qk0-x236.google.com ([2607:f8b0:400d:c09::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bNkJ8-0007lA-14 for arpug@postgresql.org; Thu, 14 Jul 2016 17:20:20 +0000 Received: by mail-qk0-x236.google.com with SMTP id 82so78727178qko.3 for ; Thu, 14 Jul 2016 10:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Osp8ygNVMfisJKgjMzBlEzAYgT9T8WYTe6hUEq9me0Y=; b=WwKriNG/QE0udvUKEGG2as99LJXEdWBlfCQb20SijzYnCsjXA++VM164NbEArtZDNj IIN9PxRocHAQL+c3uOARKpUd/sNK6l68Zxr4Wc4PM2SSYsKBfik0/Wb/mL4BGqW9NqdD +uV3xAHOrYZbCClzqKKmzXVDXbPImIgA4GwAfG6Lwyavf/4hT10h8D5p2/WWkdA2Susa PeVWm4uQFm60+ss2BmfxZi1XTLGzmYOoA0lLqmTZk8EkXeuQ8XBJ8/6E3Qi7qi/E2xEe P8H5zQvPkMmjcb6f5Yoo6BgJFzgSA3SOquVuxHVlaSkfzIHCmfwDvIoWGoWS5KXzQ+VB 0HUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Osp8ygNVMfisJKgjMzBlEzAYgT9T8WYTe6hUEq9me0Y=; b=Hu64VgJsxugV28eA2CGzQ1IQhjATGT5bL6uFgJX//UvSsG5Jjhzyn54Fq+1n2Auf2z QqAnOhgTCX5sqrSEf+0EtkF/JiHIXnNwYQHP+st7ZlroxwdRw2Z4Q42/NCg8u6V15yB+ SyyRmYvPKbUdVPJaLfFK7fs/zzisvg5Dd2trMK02hunE4E2TuPv7OjReBRtCYLJpNaTZ y12JpCNYav60oGTbQPgF56LzC6RIwmngOfYnVAEyCvw62Wz280m6UCniQH1BvLSwRLSq v0d+3ebec2K9B5PwBbUlhTCRrYnMn3g+PBd9SHSxebur+6a1D5IdJ3TA7kIWoDy5KdXH b1Wg== X-Gm-Message-State: ALyK8tLB2aeLFm6ilKg7L1TqLdZdDGtHvZAHA82p5n+g+2YYq4Bl9opWXkohecPTJ3ZoH39gvIcareiXtsbGFQ== X-Received: by 10.55.78.146 with SMTP id c140mr19912217qkb.48.1468516817255; Thu, 14 Jul 2016 10:20:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.102.235 with HTTP; Thu, 14 Jul 2016 10:20:16 -0700 (PDT) In-Reply-To: <5630f942.a627b40a.48fbe.ffffe5b2SMTPIN_ADDED_BROKEN@mx.google.com> References: <5630f942.a627b40a.48fbe.ffffe5b2SMTPIN_ADDED_BROKEN@mx.google.com> From: Emanuel Calvo Date: Thu, 14 Jul 2016 14:20:16 -0300 Message-ID: Subject: Re: Consulta To: =?UTF-8?Q?Pa=C3=BAl_Enrique_Ram=C3=ADrez?= Cc: arpug Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: arpug Precedence: bulk Sender: arpug-owner@postgresql.org La pregunta es muy general, hay varios documentos en la red para hacer esto. El gran problema quiz=C3=A1s, es que est=C3=A9n en ingles. Hay algunas tools que te pueden ayudar con esto, pero sobre todo depender= =C3=A1 mucho que tan integrada este la aplicaci=C3=B3n con Oracle. Sin ir mas lejos, podes ver estos links: http://ora2pg.darold.net/ https://www.pgcon.org/2011/schedule/attachments/205_Oracle_to_Postgres_Migr= ation.pdf https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversion El d=C3=ADa 27 de octubre de 2015, 18:16, Pa=C3=BAl Enrique Ram=C3=ADrez escribi=C3=B3: > Buenas tardes. > > Trabajo para una instituci=C3=B3n gubernamental en El Salvador. Utilizam= os bases > de datos Oracle y se est=C3=A1 evaluando la alternativa de migrar a Postg= reSQL. > > > > Me gustar=C3=ADa saber si me pueden orientar con documentos que me permit= an > prever cu=C3=A1les podr=C3=ADan ser los principales obst=C3=A1culos que s= e nos pueden > presentar en dicho proceso y qu=C3=A9 tipo de consideraciones debemos ten= er m=C3=A1s > presente. > > > > Gracias de antemano por su colaboraci=C3=B3n. > > > > > > Saludos, > > > > Ing. Pa=C3=BAl Enrique Ram=C3=ADrez > > Coordinador de Base de Datos > > Gerencia de Infraestructura Inform=C3=A1tica > > Direcci=C3=B3n de Tecnolog=C3=ADa de la Informaci=C3=B3n > > Centro Nacional de Registros > > paul.ramirez@cnr.gob.sv > > Tel=C3=A9fono: 2593-5384 > > Celular: 7160-8439 > > --=20 -- Emanuel Calvo http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services --=20 Sent via arpug mailing list (arpug@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/arpug