From brauagustin-susc@yahoo.com.ar Wed Sep  19 17:45:00 2007
Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 7BE1D9F9B61
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 14:45:00 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 98824-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 14:44:57 -0300 (ADT)
X-Greylist: delayed 00:06:40.494208 by SQLgrey-1.7.5
Received: from web30004.mail.mud.yahoo.com (web30004.mail.mud.yahoo.com
	[209.191.69.21]) by postgresql.org (Postfix) with SMTP id 0B3689F9AF7
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 14:44:55 -0300 (ADT)
Received: (qmail 87336 invoked by uid 60001); 19 Sep 2007 17:38:14 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=GWsuE9Ty+gBgsjbQhuJ8kf1zoYS6jDZZLpj4nuoeqS1fGNIaj83GbcK/uQ5U1V/row4a49KclkrTlA5h+Ru5e1lOP2XXICp82knX2kpduDZNG3cJRaWCSTV4gyjH7cLreiQmriH88knRmXUIW0WbJ2t+kfPB3Jn8z3y+80oNlYU=;
Received: from [209.191.106.123] by web30004.mail.mud.yahoo.com via HTTP;
	Wed, 19 Sep 2007 10:38:13 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Wed, 19 Sep 2007 10:38:13 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Low CPU Usage
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1326638858-1190223493=:86940"
Message-ID: <65712.86940.qm@web30004.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/318
X-Sequence-Number: 26863

--0-1326638858-1190223493=:86940
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all.=0ARecently I have installed a brand new server with a Pentium IV 3.=
2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL 8.2.4 (previou=
sly a 8.1.9).=0AI have other similar server with an IDE disk, Red Hat EL 4 =
and PostgreSQL 8.2.3=0A=0AI have almost the same postgresql.conf in both se=
rvers, but in the new one (I have more work_mem than the other one) things =
go really slow.  I began to monitor i/o disk and it's really ok, I have tes=
t disk with hdparm and it's 5 times faster than the IDE one.=0ARunning the =
same queries in both servers in the new one it envolves almost 4 minutes in=
stead of 18 seconds in the old one.=0ABoth databases are the same, I have v=
acuum them and I don't know how to manage this issue.=0AThe only weird thin=
g is than in the older server running the query it uses 30% of CPU instead =
of 3 o 5 % of the new one!!!=0AWhat's is happening with this server? I upgr=
ade from 8.1.9 to 8.2.4 trying to solve this issue but I can't find a solut=
ion.=0A=0AAny ideas?=0ARegards=0AAgustin=0A=0A=0A=0A=0A      Segu=ED de cer=
ca a la Selecci=F3n Argentina de Rugby en el Mundial de Francia 2007.=0Ahtt=
p://ar.sports.yahoo.com/mundialderugby
--0-1326638858-1190223493=:86940
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div>Hi all.<br>Recently I have installed a brand new serve=
r with a Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with Pos=
tgreSQL 8.2.4 (previously a 8.1.9).<br>I have other similar server with an =
IDE disk, Red Hat EL 4 and PostgreSQL 8.2.3<br><br>I have almost the same p=
ostgresql.conf in both servers, but in the new one (I have more work_mem th=
an the other one) things go really slow.&nbsp; I began to monitor i/o disk =
and it's really ok, I have test disk with hdparm and it's 5 times faster th=
an the IDE one.<br>Running the same queries in both servers in the new one =
it envolves almost 4 minutes instead of 18 seconds in the old one.<br>Both =
databases are the same, I have vacuum them and I don't know how to manage t=
his issue.<br>The only weird thing is than in the older server running
 the query it uses 30% of CPU instead of 3 o 5 % of the new one!!!<br>What'=
s is happening with this server? I upgrade from 8.1.9 to 8.2.4 trying to so=
lve this issue but I can't find a solution.<br><br>Any ideas?<br>Regards<br=
>Agustin<br></div></div><br>=0A      <hr size=3D1><br><font face=3D"Verdana=
" size=3D"-2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! =
Deportes:<br>=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></ht=
ml>
--0-1326638858-1190223493=:86940--



From heikki@enterprisedb.com Wed Sep  19 17:53:45 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 9D9C59F9B13
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 14:53:45 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 85272-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 14:53:39 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from mail01.enterprisedb.com (mail01.enterprisedb.com
 [63.246.7.168])
	by postgresql.org (Postfix) with ESMTP id 643349F9AB7
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 14:53:41 -0300 (ADT)
thread-index: Acf65gxV5+ojLSRhRtWMqXAJ0pRfvw==
Received: from [192.168.1.33] ([82.3.228.35]) by mail01.enterprisedb.com over
	TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);
	Wed, 19 Sep 2007 13:53:53 -0400
Message-ID: <46F161F3.1070601@enterprisedb.com>
Content-Class: urn:content-classes:message
Date: Wed, 19 Sep 2007 18:52:51 +0100
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073
From: "Heikki Linnakangas" <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.12 (X11/20070730)
MIME-Version: 1.0
To: <brauagustin-susc@yahoo.com.ar>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: Low CPU Usage
References: <65712.86940.qm@web30004.mail.mud.yahoo.com>
In-Reply-To: <65712.86940.qm@web30004.mail.mud.yahoo.com>
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Sep 2007 17:53:53.0687 (UTC)
	FILETIME=[0AF92270:01C7FAE6]
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/319
X-Sequence-Number: 26864

brauagustin-susc@yahoo.com.ar wrote:
> Recently I have installed a brand new server with a Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL 8.2.4 (previously a 8.1.9).
> I have other similar server with an IDE disk, Red Hat EL 4 and PostgreSQL 8.2.3
> 
> I have almost the same postgresql.conf in both servers, but in the new one (I have more work_mem than the other one) things go really slow.  I began to monitor i/o disk and it's really ok, I have test disk with hdparm and it's 5 times faster than the IDE one.
> Running the same queries in both servers in the new one it envolves almost 4 minutes instead of 18 seconds in the old one.
> Both databases are the same, I have vacuum them and I don't know how to manage this issue.

Have you ANALYZEd all tables?

Try running EXPLAIN ANALYZE on the query on both servers, and see if
they're using the same plan.

> The only weird thing is than in the older server running the query it uses 30% of CPU instead of 3 o 5 % of the new one!!!

That implies that it's doing much more I/O on the new server, so the CPU
just sits and waits for data to arrive from the disk.

That does iostat say about disk utilization on both servers?

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com



From mark.lewis@mir3.com Wed Sep  19 18:03:22 2007
Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id E37AD9FA253
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 15:03:22 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 22314-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 15:03:11 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100])
	by postgresql.org (Postfix) with ESMTP id BD3549FA0D0
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 15:03:10 -0300 (ADT)
Received: MIR3-FS.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP
	with MS-WebStorage 6.0.6249
Received: from archimedes by MIR3-FS.mir3.com; 19 Sep 2007 11:03:06 -0700
Subject: Re: Low CPU Usage
From: Mark Lewis <mark.lewis@mir3.com>
To: brauagustin-susc@yahoo.com.ar
Cc: pgsql-performance@postgresql.org
In-Reply-To: <65712.86940.qm@web30004.mail.mud.yahoo.com>
References: <65712.86940.qm@web30004.mail.mud.yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: MIR3, Inc.
Date: Wed, 19 Sep 2007 11:03:06 -0700
Message-Id: <1190224986.11528.47.camel@archimedes>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/320
X-Sequence-Number: 26865

On Wed, 2007-09-19 at 10:38 -0700, brauagustin-susc@yahoo.com.ar wrote:
> Hi all.
> Recently I have installed a brand new server with a Pentium IV 3.2
> GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL 8.2.4
> (previously a 8.1.9).
> I have other similar server with an IDE disk, Red Hat EL 4 and
> PostgreSQL 8.2.3
> 
> I have almost the same postgresql.conf in both servers, but in the new
> one (I have more work_mem than the other one) things go really slow.
> I began to monitor i/o disk and it's really ok, I have test disk with
> hdparm and it's 5 times faster than the IDE one.
> Running the same queries in both servers in the new one it envolves
> almost 4 minutes instead of 18 seconds in the old one.
> Both databases are the same, I have vacuum them and I don't know how
> to manage this issue.
> The only weird thing is than in the older server running the query it
> uses 30% of CPU instead of 3 o 5 % of the new one!!!
> What's is happening with this server? I upgrade from 8.1.9 to 8.2.4
> trying to solve this issue but I can't find a solution.
> 
> Any ideas?

It could be a planning issue.  Have you analyzed the new database to
gather up-to-date statistics?  A comparison of EXPLAIN ANALYZE results
for an example query in both systems should answer that one.

Another possibility because you're dealing with lower-end drives is that
you have a case of one drive lying about fsync where the other is not.
If possible, try running your test with fsync=off on both servers.  If
there's a marked improvement on the new server but no significant change
on the old server then you've found your culprit.

-- Mark Lewis




From brauagustin-susc@yahoo.com.ar Wed Sep  19 19:13:42 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 543479FA4E1
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:13:42 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 59493-09-2
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:13:33 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30002.mail.mud.yahoo.com (web30002.mail.mud.yahoo.com
	[209.191.69.19]) by postgresql.org (Postfix) with SMTP id 569029F9D1C
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 16:13:35 -0300 (ADT)
Received: (qmail 63549 invoked by uid 60001); 19 Sep 2007 19:13:33 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=FRmi+Z3201ONfVO1MNLnokPmzN4WcL+SHLJJzWi5WkcKUWtv2aTSFghF13F+gZ/EPkE6CIfV+ZFGgOPmX/E6epdpOyXDUrcXpiqy/BRiuHCSEIFnHVa2yxXnAKA7k3QMN6AC+LRbj21Hp6sEPsNSe/DNgFv+XmZneU+tF63ZXh8=;
X-YMail-OSG: 
 pqYaS6AVM1kpRHfUtHEq9SC9i3i11ZbU4Z2mdzZJMoSbHVKeIpnYlwZj9iKPQndTrw--
Received: from [209.191.106.123] by web30002.mail.mud.yahoo.com via HTTP;
	Wed, 19 Sep 2007 12:13:33 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Wed, 19 Sep 2007 12:13:33 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-42887485-1190229213=:63342"
Message-ID: <618808.63342.qm@web30002.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/321
X-Sequence-Number: 26866

--0-42887485-1190229213=:63342
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

No, changing to fsync off didn't improve performance at all.=0ASettings=0Aw=
ork_mem =3D 64MB=0Amax_stack_depth =3D 7MB #in the old server is 8MB but if=
 I set in here give me the ulimit error=0Amax_fsm_pages =3D 204800=0Aeffect=
ive_cache_size =3D 512MB=0AAtuvacuum is off.=0A=0AI have run vacuum full an=
d vacuum analyze. The databases are freezed (there are no insert, update or=
 delete operations)!!! =0AIn both servers the query plans are identical wit=
h the same costs too!!!=0A=0AIt's really weird, I don't see high values mon=
itoring disk. Cpu usage is about 5% and sometimes a tips of 40 % of disk us=
age=0A when the query is finishing (the first 3 minutes there are some tips=
 of 11 to 16%).=0A=0A=0A=0A=0A=0A=0A----- Mensaje original ----=0ADe: Mark =
Lewis <mark.lewis@mir3.com>=0APara: brauagustin-susc@yahoo.com.ar=0ACC: pgs=
ql-performance@postgresql.org=0AEnviado: mi=E9rcoles 19 de septiembre de 20=
07, 15:03:06=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AOn Wed, 2007-09-19 =
at 10:38 -0700, brauagustin-susc@yahoo.com.ar wrote:=0A> Hi all.=0A> Recent=
ly I have installed a brand new server with a Pentium IV 3.2=0A> GHz, SATA =
Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL 8.2.4=0A> (previously a 8.=
1.9).=0A> I have other similar server with an IDE disk, Red Hat EL 4 and=0A=
> PostgreSQL 8.2.3=0A> =0A> I have almost the same postgresql.conf in both =
servers, but in the new=0A> one (I have more work_mem than the other one) t=
hings go really slow.=0A> I began to monitor i/o disk and it's really ok, I=
 have test disk with=0A> hdparm and it's 5 times faster than the IDE one.=
=0A> Running the same queries in both servers in the new one it envolves=0A=
> almost 4 minutes instead of 18 seconds in the old one.=0A> Both databases=
 are the same, I have vacuum them and I don't know how=0A> to manage this i=
ssue.=0A> The only weird thing is than in the older server running the quer=
y it=0A> uses 30% of CPU instead of 3 o 5 % of the new one!!!=0A> What's is=
 happening with this server? I upgrade from 8.1.9 to 8.2.4=0A> trying to so=
lve this issue but I can't find a solution.=0A> =0A> Any ideas?=0A=0AIt cou=
ld be a planning issue.  Have you analyzed the new database to=0Agather up-=
to-date statistics?  A comparison of EXPLAIN ANALYZE results=0Afor an examp=
le query in both systems should answer that one.=0A=0AAnother possibility b=
ecause you're dealing with lower-end drives is that=0Ayou have a case of on=
e drive lying about fsync where the other is not.=0AIf possible, try runnin=
g your test with fsync=3Doff on both servers.  If=0Athere's a marked improv=
ement on the new server but no significant change=0Aon the old server then =
you've found your culprit.=0A=0A-- Mark Lewis=0A=0A=0A---------------------=
------(end of broadcast)---------------------------=0ATIP 2: Don't 'kill -9=
' the postmaster=0A=0A=0A=0A=0A=0A=0A=0A      Las =FAltimas noticias sobre =
el Mundial de Rugby 2007 est=E1n en Yahoo! Deportes. =A1Conocelas!=0Ahttp:/=
/ar.sports.yahoo.com/mundialderugby
--0-42887485-1190229213=:63342
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;"><div style=3D"font-family: times new roman,new york=
,times,serif; font-size: 12pt;"><div style=3D"font-family: times new roman,=
new york,times,serif; font-size: 12pt;">No, changing to fsync off didn't im=
prove performance at all.<br><div style=3D"font-family: times new roman,new=
 york,times,serif; font-size: 12pt;"><div style=3D"font-family: times new r=
oman,new york,times,serif; font-size: 12pt;"><div style=3D"font-family: tim=
es new roman,new york,times,serif; font-size: 12pt;">Settings<br>work_mem =
=3D 64MB<br>max_stack_depth =3D 7MB #in the old server is 8MB but if I set =
in here give me the ulimit error<br>max_fsm_pages =3D 204800<br>effective_c=
ache_size =3D 512MB<br>Atuvacuum is off.<br><br>I have run vacuum full and =
vacuum analyze.
 The databases are freezed (there are no insert, update or delete operation=
s)!!! <br>In both servers the query plans are identical with the same costs=
 too!!!<br><br>It's really weird, I don't see high values monitoring disk. =
Cpu usage is about 5% and sometimes a tips of 40 % of disk usage=0A when th=
e query is finishing (the first 3 minutes there are some tips of 11 to 16%)=
.</div></div></div></div></div><br><br><div style=3D"font-family: times new=
 roman,new york,times,serif; font-size: 12pt;">----- Mensaje original ----<=
br>De: Mark Lewis &lt;mark.lewis@mir3.com&gt;<br>Para: brauagustin-susc@yah=
oo.com.ar<br>CC: pgsql-performance@postgresql.org<br>Enviado: mi=E9rcoles 1=
9 de septiembre de 2007, 15:03:06<br>Asunto: Re: [PERFORM] Low CPU Usage<br=
><br><div>On Wed, 2007-09-19 at 10:38 -0700, brauagustin-susc@yahoo.com.ar =
wrote:<br>&gt; Hi all.<br>&gt; Recently I have installed a brand new server=
 with a Pentium IV 3.2<br>&gt; GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 w=
ith PostgreSQL 8.2.4<br>&gt; (previously a 8.1.9).<br>&gt; I have other sim=
ilar server with an IDE disk, Red Hat EL 4 and<br>&gt; PostgreSQL 8.2.3<br>=
&gt; <br>&gt; I have almost the same postgresql.conf in both servers, but i=
n the new<br>&gt; one (I have more work_mem than the other one)
 things go really slow.<br>&gt; I began to monitor i/o disk and it's really=
 ok, I have test disk with<br>&gt; hdparm and it's 5 times faster than the =
IDE one.<br>&gt; Running the same queries in both servers in the new one it=
 envolves<br>&gt; almost 4 minutes instead of 18 seconds in the old one.<br=
>&gt; Both databases are the same, I have vacuum them and I don't know how<=
br>&gt; to manage this issue.<br>&gt; The only weird thing is than in the o=
lder server running the query it<br>&gt; uses 30% of CPU instead of 3 o 5 %=
 of the new one!!!<br>&gt; What's is happening with this server? I upgrade =
from 8.1.9 to 8.2.4<br>&gt; trying to solve this issue but I can't find a s=
olution.<br>&gt; <br>&gt; Any ideas?<br><br>It could be a planning issue.&n=
bsp;&nbsp;Have you analyzed the new database to<br>gather up-to-date statis=
tics?&nbsp;&nbsp;A comparison of EXPLAIN ANALYZE results<br>for an example =
query in both systems should answer that one.<br><br>Another
 possibility because you're dealing with lower-end drives is that<br>you ha=
ve a case of one drive lying about fsync where the other is not.<br>If poss=
ible, try running your test with fsync=3Doff on both servers.&nbsp;&nbsp;If=
<br>there's a marked improvement on the new server but no significant chang=
e<br>on the old server then you've found your culprit.<br><br>-- Mark Lewis=
<br><br><br>---------------------------(end of broadcast)------------------=
---------<br>TIP 2: Don't 'kill -9' the postmaster<br></div></div><br></div=
></div><br>=0A=0A=0A=0A      <hr size=3D1><br><font face=3D"Verdana" size=
=3D"-2">Los referentes m=E1s importantes en compra/venta de autos se juntar=
on:<br>Demotores y Yahoo!.=0AAhora comprar o vender tu auto es m=E1s f=E1ci=
l. <br> Visit=E1 http://ar.autos.yahoo.com/</font></body></html>
--0-42887485-1190229213=:63342--



From scott.marlowe@gmail.com Wed Sep  19 19:41:54 2007
Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 7827B9FA6B3
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:41:54 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 67031-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:41:47 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173])
	by postgresql.org (Postfix) with ESMTP id E04DD9FA615
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 16:41:46 -0300 (ADT)
Received: by ug-out-1314.google.com with SMTP id j3so313518ugf
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 12:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	bh=nDA0rV1YO4YbukdmhLPXo61tyhI8MEGp+qA2T6TJ/9w=;
	b=VlMtos1WduA9SbcdC1bItSEfCyiCcl9fXbN4z7ruf/IkHXwMeLwL1STlkQlmnWyECHy/J9zrKsyX/pjtwZPB64dkhQTBnV3JbEQth/e1FE0b+6D7sKIkrDZWL4BJKiq64WfQ1hBmxikM5HunyjICBtvwg2y1rsKiSPi0gfPtokM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=ryTjRjbjtP94Ze23yoErDgAs7aQB7e6DSkomBAS+gXBlduAQDTJte6DjmI76goBI0Id5PpGviAfnXJHKJA0gZOvUQLhULobQkyUGS4fnVdiBfGttNtWw4NCAHKQOBHyNx6g8FeZodzP3GK6WIhfxuJcNgBqqkC0+8d/1Z8AQkXs=
Received: by 10.67.31.5 with SMTP id i5mr1536453ugj.1190230905366;
	Wed, 19 Sep 2007 12:41:45 -0700 (PDT)
Received: by 10.66.220.7 with HTTP; Wed, 19 Sep 2007 12:41:45 -0700 (PDT)
Message-ID: <dcc563d10709191241q3c861ee9td56e409452411059@mail.gmail.com>
Date: Wed, 19 Sep 2007 14:41:45 -0500
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: "brauagustin-susc@yahoo.com.ar" <brauagustin-susc@yahoo.com.ar>
Subject: Re: Low CPU Usage
Cc: pgsql-performance@postgresql.org
In-Reply-To: <618808.63342.qm@web30002.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <618808.63342.qm@web30002.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/322
X-Sequence-Number: 26867

On 9/19/07, brauagustin-susc@yahoo.com.ar <brauagustin-susc@yahoo.com.ar> wrote:
>
>
> No, changing to fsync off didn't improve performance at all.
>
> Settings
> work_mem = 64MB
> max_stack_depth = 7MB #in the old server is 8MB but if I set in here give me
> the ulimit error
> max_fsm_pages = 204800
> effective_cache_size = 512MB
> Atuvacuum is off.
>
> I have run vacuum full and vacuum analyze. The databases are freezed (there
> are no insert, update or delete operations)!!!
> In both servers the query plans are identical with the same costs too!!!
>
> It's really weird, I don't see high values monitoring disk. Cpu usage is
> about 5% and sometimes a tips of 40 % of disk usage when the query is
> finishing (the first 3 minutes there are some tips of 11 to 16%).

(please don't top post)

This sounds like you've got problems somewhere in your I/O system.
hdparm etc may or may not be seeing the issue.  What do you see in
/var/log/messages or dmesg?



From brauagustin-susc@yahoo.com.ar Wed Sep  19 19:52:54 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 1045F9F9B7C
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:52:54 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 69999-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 16:52:43 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30003.mail.mud.yahoo.com (web30003.mail.mud.yahoo.com
	[209.191.69.20]) by postgresql.org (Postfix) with SMTP id 91D189F9B78
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 16:52:45 -0300 (ADT)
Received: (qmail 19597 invoked by uid 60001); 19 Sep 2007 19:52:44 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=ktdWAsd+oCRwzTyM2BHoLyFaakveryjNFRWVHfOcDGV90j9thao+Mtneq6D6//nyZPPqjqIT1nbnB7jI0LUK3FhgjUYDhu0v5h69vMXTNLK8jh/ZIUJn9dFzcG/UayzdP8fPoCBoKhi8Rynz5HLgCpaG74SYeBeLi4y/KEfvYAg=;
X-YMail-OSG: 
 OIKl.64VM1n9dS1ftfsROGuwRlVikHJIhjYfM.noZi49kCDY9q8HG2ZbJKJb4GNX.4eZ4RtiZVGUT_mnlbFhPJTiC0oAO5xK0nsW3l90yA0pwn_vGJhxdKbq_yCGfg--
Received: from [209.191.106.123] by web30003.mail.mud.yahoo.com via HTTP;
	Wed, 19 Sep 2007 12:52:43 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Wed, 19 Sep 2007 12:52:43 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1434099264-1190231563=:18461"
Message-ID: <27902.18461.qm@web30003.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/323
X-Sequence-Number: 26868

--0-1434099264-1190231563=:18461
Content-Type: multipart/alternative; boundary="0-215091696-1190231563=:18461"

--0-215091696-1190231563=:18461
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This is my dmesg file, I see there are some errors but I don't know how to =
manage!!!=0A=0AWhat do you mean with don't top post?=0ASorry but I'm new wi=
th this kind of mailing list and I don't want to botter some others.=0ASorr=
y my bad English too.=0AThanks for your help=0A=0A=0A=0A----- Mensaje origi=
nal ----=0ADe: Scott Marlowe <scott.marlowe@gmail.com>=0APara: "brauagustin=
-susc@yahoo.com.ar" <brauagustin-susc@yahoo.com.ar>=0ACC: pgsql-performance=
@postgresql.org=0AEnviado: mi=E9rcoles 19 de septiembre de 2007, 16:41:45=
=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AOn 9/19/07, brauagustin-susc@ya=
hoo.com.ar <brauagustin-susc@yahoo.com.ar> wrote:=0A>=0A>=0A> No, changing =
to fsync off didn't improve performance at all.=0A>=0A> Settings=0A> work_m=
em =3D 64MB=0A> max_stack_depth =3D 7MB #in the old server is 8MB but if I =
set in here give me=0A> the ulimit error=0A> max_fsm_pages =3D 204800=0A> e=
ffective_cache_size =3D 512MB=0A> Atuvacuum is off.=0A>=0A> I have run vacu=
um full and vacuum analyze. The databases are freezed (there=0A> are no ins=
ert, update or delete operations)!!!=0A> In both servers the query plans ar=
e identical with the same costs too!!!=0A>=0A> It's really weird, I don't s=
ee high values monitoring disk. Cpu usage is=0A> about 5% and sometimes a t=
ips of 40 % of disk usage when the query is=0A> finishing (the first 3 minu=
tes there are some tips of 11 to 16%).=0A=0A(please don't top post)=0A=0ATh=
is sounds like you've got problems somewhere in your I/O system.=0Ahdparm e=
tc may or may not be seeing the issue.  What do you see in=0A/var/log/messa=
ges or dmesg?=0A=0A=0A=0A=0A=0A=0A=0A      Los referentes m=E1s importantes=
 en compra/ venta de autos se juntaron:=0ADemotores y Yahoo!=0AAhora compra=
r o vender tu auto es m=E1s f=E1cil. Vist=E1 ar.autos.yahoo.com/
--0-215091696-1190231563=:18461
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">This is my dmesg file, I see there are some errors =
but I don't know how to manage!!!<br><br>What do you mean with don't top po=
st?<br>Sorry but I'm new with this kind of mailing list and I don't want to=
 botter some others.<br>Sorry my bad English too.<br>Thanks for your help<b=
r><br><br><br><div style=3D"font-family: times new roman,new york,times,ser=
if; font-size: 12pt;">----- Mensaje original ----<br>De: Scott Marlowe &lt;=
scott.marlowe@gmail.com&gt;<br>Para: "brauagustin-susc@yahoo.com.ar" &lt;br=
auagustin-susc@yahoo.com.ar&gt;<br>CC: pgsql-performance@postgresql.org<br>=
Enviado: mi=E9rcoles 19 de septiembre de 2007, 16:41:45<br>Asunto: Re: [PER=
FORM] Low CPU Usage<br><br><div>On 9/19/07, brauagustin-susc@yahoo.com.ar
 &lt;brauagustin-susc@yahoo.com.ar&gt; wrote:<br>&gt;<br>&gt;<br>&gt; No, c=
hanging to fsync off didn't improve performance at all.<br>&gt;<br>&gt; Set=
tings<br>&gt; work_mem =3D 64MB<br>&gt; max_stack_depth =3D 7MB #in the old=
 server is 8MB but if I set in here give me<br>&gt; the ulimit error<br>&gt=
; max_fsm_pages =3D 204800<br>&gt; effective_cache_size =3D 512MB<br>&gt; A=
tuvacuum is off.<br>&gt;<br>&gt; I have run vacuum full and vacuum analyze.=
 The databases are freezed (there<br>&gt; are no insert, update or delete o=
perations)!!!<br>&gt; In both servers the query plans are identical with th=
e same costs too!!!<br>&gt;<br>&gt; It's really weird, I don't see high val=
ues monitoring disk. Cpu usage is<br>&gt; about 5% and sometimes a tips of =
40 % of disk usage when the query is<br>&gt; finishing (the first 3 minutes=
 there are some tips of 11 to 16%).<br><br>(please don't top post)<br><br>T=
his sounds like you've got problems somewhere in your I/O system.<br>hdparm
 etc may or may not be seeing the issue.&nbsp;&nbsp;What do you see in<br>/=
var/log/messages or dmesg?<br></div></div><br></div></div><br>=0A      <hr =
size=3D1><br><font face=3D"Verdana" size=3D"-2">Segu=ED de cerca a la Selec=
ci=F3n Argentina de Rugby<br>en el Mundial de Francia 2007.<br>=0Ahttp://ar=
.sports.yahoo.com/mundialderugby</font></body></html>
--0-215091696-1190231563=:18461--

--0-1434099264-1190231563=:18461
Content-Type: application/octet-stream; name="=?utf-8?q?dmesg?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?utf-8?q?dmesg?="

TGludXggdmVyc2lvbiAyLjYuMTgtNS02ODYgKERlYmlhbiAyLjYuMTguZGZz
Zy4xLTEzZXRjaDIpIChkYW5uZkBkZWJpYW4ub3JnKSAoZ2NjIHZlcnNpb24g
NC4xLjIgMjAwNjExMTUgKHByZXJlbGVhc2UpIChEZWJpYW4gNC4xLjEtMjEp
KSAjMSBTTVAgVGh1IEF1ZyAzMCAwMjoxOTowNyBVVEMgMjAwNwpCSU9TLXBy
b3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6CiBCSU9TLWU4MjA6IDAwMDAwMDAw
MDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmYzAwICh1c2FibGUpCiBCSU9TLWU4
MjA6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNl
cnZlZCkKIEJJT1MtZTgyMDogMDAwMDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAw
MDAxMDAwMDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAwMDAwMTAw
MDAwIC0gMDAwMDAwMDA3ZmZmMDAwMCAodXNhYmxlKQogQklPUy1lODIwOiAw
MDAwMDAwMDdmZmYwMDAwIC0gMDAwMDAwMDA3ZmZmZTAwMCAoQUNQSSBkYXRh
KQogQklPUy1lODIwOiAwMDAwMDAwMDdmZmZlMDAwIC0gMDAwMDAwMDA4MDAw
MDAwMCAoQUNQSSBOVlMpCiBCSU9TLWU4MjA6IDAwMDAwMDAwZmVlMDAwMDAg
LSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkKMTE1MU1CIEhJR0hNRU0g
YXZhaWxhYmxlLgo4OTZNQiBMT1dNRU0gYXZhaWxhYmxlLgpmb3VuZCBTTVAg
TVAtdGFibGUgYXQgMDAwZmY3ODAKT24gbm9kZSAwIHRvdGFscGFnZXM6IDUy
NDI3MgogIERNQSB6b25lOiA0MDk2IHBhZ2VzLCBMSUZPIGJhdGNoOjAKICBO
b3JtYWwgem9uZTogMjI1MjgwIHBhZ2VzLCBMSUZPIGJhdGNoOjMxCiAgSGln
aE1lbSB6b25lOiAyOTQ4OTYgcGFnZXMsIExJRk8gYmF0Y2g6MzEKRE1JIDIu
MyBwcmVzZW50LgpBQ1BJOiBSU0RQICh2MDAyIEFDUElBTSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKSBAIDB4MDAwZmFiMDAKQUNQSTogWFNE
VCAodjAwMSBIUCAgICAgT0VNWFNEVCAgMHgwNDAwMDYxOSBNU0ZUIDB4MDAw
MDAwOTcpIEAgMHg3ZmZmMDEwMApBQ1BJOiBGQURUICh2MDAzIEhQICAgICBP
RU1GQUNQICAweDA0MDAwNjE5IE1TRlQgMHgwMDAwMDA5NykgQCAweDdmZmYw
MjkwCkFDUEk6IE1BRFQgKHYwMDEgSFAgICAgIE9FTUFQSUMgIDB4MDQwMDA2
MTkgTVNGVCAweDAwMDAwMDk3KSBAIDB4N2ZmZjAzOTAKQUNQSTogTUNGRyAo
djAwMSBIUCAgICAgT0VNTUNGRyAgMHgwNDAwMDYxOSBNU0ZUIDB4MDAwMDAw
OTcpIEAgMHg3ZmZmMDQ2MApBQ1BJOiBPRU1CICh2MDAxIEhQICAgICBIUF9P
RU0gICAweDA0MDAwNjE5IE1TRlQgMHgwMDAwMDA5NykgQCAweDdmZmZlMDQw
CkFDUEk6IERTRFQgKHYwMDEgSFAgICAgIENQUU82MTIxIDB4MDAwMDAxMjEg
SU5UTCAweDAyMDAyMDI2KSBAIDB4MDAwMDAwMDAKQUNQSTogUE0tVGltZXIg
SU8gUG9ydDogMHg4MDgKQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVl
MDAwMDAKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgw
MF0gZW5hYmxlZCkKUHJvY2Vzc29yICMwIDE1OjQgQVBJQyB2ZXJzaW9uIDIw
CkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVu
YWJsZWQpClByb2Nlc3NvciAjMSAxNTo0IEFQSUMgdmVyc2lvbiAyMApBQ1BJ
OiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19pZFsweDgyXSBkaXNhYmxl
ZCkKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHg4M10g
ZGlzYWJsZWQpCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAxXSBkZmwg
ZGZsIGxpbnRbMHhhXSkKQUNQSTogTk1JIG5vdCBjb25uZWN0ZWQgdG8gTElO
VCAxIQpBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhmZWMwMDAw
MF0gZ3NpX2Jhc2VbMF0pCklPQVBJQ1swXTogYXBpY19pZCAyLCB2ZXJzaW9u
IDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCkFDUEk6IElOVF9T
UkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwp
CkFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2ly
cSA5IGhpZ2ggbGV2ZWwpCkFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4K
QUNQSTogSVJRMiB1c2VkIGJ5IG92ZXJyaWRlLgpBQ1BJOiBJUlE5IHVzZWQg
Ynkgb3ZlcnJpZGUuCkVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2lu
ZyAxIEkvTyBBUElDcwpVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZp
Z3VyYXRpb24gaW5mb3JtYXRpb24KQWxsb2NhdGluZyBQQ0kgcmVzb3VyY2Vz
IHN0YXJ0aW5nIGF0IDg4MDAwMDAwIChnYXA6IDgwMDAwMDAwOjdlZTAwMDAw
KQpEZXRlY3RlZCAzMjAwLjMyNyBNSHogcHJvY2Vzc29yLgpCdWlsdCAxIHpv
bmVsaXN0cy4gIFRvdGFsIHBhZ2VzOiA1MjQyNzIKS2VybmVsIGNvbW1hbmQg
bGluZTogcm9vdD0vZGV2L3NkYTIgcm8gCm1hcHBlZCBBUElDIHRvIGZmZmZk
MDAwIChmZWUwMDAwMCkKbWFwcGVkIElPQVBJQyB0byBmZmZmYzAwMCAoZmVj
MDAwMDApCkVuYWJsaW5nIGZhc3QgRlBVIHNhdmUgYW5kIHJlc3RvcmUuLi4g
ZG9uZS4KRW5hYmxpbmcgdW5tYXNrZWQgU0lNRCBGUFUgZXhjZXB0aW9uIHN1
cHBvcnQuLi4gZG9uZS4KSW5pdGlhbGl6aW5nIENQVSMwClBJRCBoYXNoIHRh
YmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAxMiwgMTYzODQgYnl0ZXMpCkNv
bnNvbGU6IGNvbG91ciBWR0ErIDgweDI1CkRlbnRyeSBjYWNoZSBoYXNoIHRh
YmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykK
SW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6
IDYsIDI2MjE0NCBieXRlcykKTWVtb3J5OiAyMDcxNDcyay8yMDk3MDg4ayBh
dmFpbGFibGUgKDE1NDFrIGtlcm5lbCBjb2RlLCAyNDI4OGsgcmVzZXJ2ZWQs
IDU3NmsgZGF0YSwgMTk2ayBpbml0LCAxMTc5NTg0ayBoaWdobWVtKQpDaGVj
a2luZyBpZiB0aGlzIHByb2Nlc3NvciBob25vdXJzIHRoZSBXUCBiaXQgZXZl
biBpbiBzdXBlcnZpc29yIG1vZGUuLi4gT2suCkNhbGlicmF0aW5nIGRlbGF5
IHVzaW5nIHRpbWVyIHNwZWNpZmljIHJvdXRpbmUuLiA2NDA2LjAxIEJvZ29N
SVBTIChscGo9MTI4MTIwMjgpClNlY3VyaXR5IEZyYW1ld29yayB2MS4wLjAg
aW5pdGlhbGl6ZWQKU0VMaW51eDogIERpc2FibGVkIGF0IGJvb3QuCkNhcGFi
aWxpdHkgTFNNIGluaXRpYWxpemVkCk1vdW50LWNhY2hlIGhhc2ggdGFibGUg
ZW50cmllczogNTEyCkNQVTogQWZ0ZXIgZ2VuZXJpYyBpZGVudGlmeSwgY2Fw
czogYmZlYmZiZmYgMjAxMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDY0
OWQgMDAwMDAwMDAgMDAwMDAwMDEKQ1BVOiBBZnRlciB2ZW5kb3IgaWRlbnRp
ZnksIGNhcHM6IGJmZWJmYmZmIDIwMTAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw
IDAwMDA2NDlkIDAwMDAwMDAwIDAwMDAwMDAxCm1vbml0b3IvbXdhaXQgZmVh
dHVyZSBwcmVzZW50Lgp1c2luZyBtd2FpdCBpbiBpZGxlIHRocmVhZHMuCkNQ
VTogVHJhY2UgY2FjaGU6IDEySyB1b3BzLCBMMSBEIGNhY2hlOiAxNksKQ1BV
OiBMMiBjYWNoZTogMjA0OEsKQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6
IDAKQ1BVOiBBZnRlciBhbGwgaW5pdHMsIGNhcHM6IGJmZWJmYmZmIDIwMTAw
MDAwIDAwMDAwMDAwIDAwMDAwMTgwIDAwMDA2NDlkIDAwMDAwMDAwIDAwMDAw
MDAxCkludGVsIG1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlIHN1cHBvcnRl
ZC4KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZCBvbiBD
UFUjMC4KQ1BVMDogSW50ZWwgUDQvWGVvbiBFeHRlbmRlZCBNQ0UgTVNScyAo
MjQpIGF2YWlsYWJsZQpDUFUwOiBUaGVybWFsIG1vbml0b3JpbmcgZW5hYmxl
ZApDb21wYXQgdkRTTyBtYXBwZWQgdG8gZmZmZmUwMDAuCkNoZWNraW5nICdo
bHQnIGluc3RydWN0aW9uLi4uIE9LLgpTTVAgYWx0ZXJuYXRpdmVzOiBzd2l0
Y2hpbmcgdG8gVVAgY29kZQpBQ1BJOiBDb3JlIHJldmlzaW9uIDIwMDYwNzA3
CkNQVTA6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMy4yMEdIeiBzdGVw
cGluZyAwYQpTTVAgYWx0ZXJuYXRpdmVzOiBzd2l0Y2hpbmcgdG8gU01QIGNv
ZGUKQm9vdGluZyBwcm9jZXNzb3IgMS8xIGVpcCAzMDAwCkluaXRpYWxpemlu
ZyBDUFUjMQpDYWxpYnJhdGluZyBkZWxheSB1c2luZyB0aW1lciBzcGVjaWZp
YyByb3V0aW5lLi4gNjQwMC43MSBCb2dvTUlQUyAobHBqPTEyODAxNDIxKQpD
UFU6IEFmdGVyIGdlbmVyaWMgaWRlbnRpZnksIGNhcHM6IGJmZWJmYmZmIDIw
MTAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDA2NDlkIDAwMDAwMDAwIDAw
MDAwMDAxCkNQVTogQWZ0ZXIgdmVuZG9yIGlkZW50aWZ5LCBjYXBzOiBiZmVi
ZmJmZiAyMDEwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwNjQ5ZCAwMDAw
MDAwMCAwMDAwMDAwMQptb25pdG9yL213YWl0IGZlYXR1cmUgcHJlc2VudC4K
Q1BVOiBUcmFjZSBjYWNoZTogMTJLIHVvcHMsIEwxIEQgY2FjaGU6IDE2SwpD
UFU6IEwyIGNhY2hlOiAyMDQ4SwpDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJ
RDogMApDUFU6IEFmdGVyIGFsbCBpbml0cywgY2FwczogYmZlYmZiZmYgMjAx
MDAwMDAgMDAwMDAwMDAgMDAwMDAxODAgMDAwMDY0OWQgMDAwMDAwMDAgMDAw
MDAwMDEKSW50ZWwgbWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUgc3VwcG9y
dGVkLgpJbnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkIG9u
IENQVSMxLgpDUFUxOiBJbnRlbCBQNC9YZW9uIEV4dGVuZGVkIE1DRSBNU1Jz
ICgyNCkgYXZhaWxhYmxlCkNQVTE6IFRoZXJtYWwgbW9uaXRvcmluZyBlbmFi
bGVkCkNQVTE6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMy4yMEdIeiBz
dGVwcGluZyAwYQpUb3RhbCBvZiAyIHByb2Nlc3NvcnMgYWN0aXZhdGVkICgx
MjgwNi43MiBCb2dvTUlQUykuCkVOQUJMSU5HIElPLUFQSUMgSVJRcwouLlRJ
TUVSOiB2ZWN0b3I9MHgzMSBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4y
PS0xCmNoZWNraW5nIFRTQyBzeW5jaHJvbml6YXRpb24gYWNyb3NzIDIgQ1BV
czogCkNQVSMwIGhhZCAtMjM2ODc0IHVzZWNzIFRTQyBza2V3LCBmaXhlZCBp
dCB1cC4KQ1BVIzEgaGFkIDIzNjg3NCB1c2VjcyBUU0Mgc2tldywgZml4ZWQg
aXQgdXAuCkJyb3VnaHQgdXAgMiBDUFVzCm1pZ3JhdGlvbl9jb3N0PTExCmNo
ZWNraW5nIGlmIGltYWdlIGlzIGluaXRyYW1mcy4uLiBpdCBpcwpGcmVlaW5n
IGluaXRyZCBtZW1vcnk6IDQzNzhrIGZyZWVkCk5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgMTYKQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVy
ZWQKUENJOiBCSU9TIEJ1ZzogTUNGRyBhcmVhIGF0IGYwMDAwMDAwIGlzIG5v
dCBFODIwLXJlc2VydmVkClBDSTogTm90IHVzaW5nIE1NQ09ORklHLgpQQ0k6
IFBDSSBCSU9TIHJldmlzaW9uIDMuMDAgZW50cnkgYXQgMHhmMDAzMSwgbGFz
dCBidXM9OApQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxClNldHRp
bmcgdXAgc3RhbmRhcmQgUENJIHJlc291cmNlcwpBQ1BJOiBJbnRlcnByZXRl
ciBlbmFibGVkCkFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0IHJv
dXRpbmcKQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kwXSAoMDAwMDowMCkK
UENJOiBQcm9iaW5nIFBDSSBoYXJkd2FyZSAoYnVzIDAwKQpQQ0k6IElnbm9y
aW5nIEJBUjAtMyBvZiBJREUgY29udHJvbGxlciAwMDAwOjAwOjFmLjEKQm9v
dCB2aWRlbyBkZXZpY2UgaXMgMDAwMDowODowMi4wClBDSTogVHJhbnNwYXJl
bnQgYnJpZGdlIC0gMDAwMDowMDoxZS4wCkFDUEk6IFBDSSBJbnRlcnJ1cHQg
Um91dGluZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpBQ1BJOiBQQ0kgSW50
ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUDBQMS5fUFJUXQpB
Q1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAu
UDBQOS5fUFJUXQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJ
UlFzIDMgNCA1IDYgNyAqMTAgMTEgMTIgMTQgMTUpCkFDUEk6IFBDSSBJbnRl
cnJ1cHQgTGluayBbTE5LQl0gKElSUXMgMyA0IDUgNiA3IDEwICoxMSAxMiAx
NCAxNSkKQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAz
IDQgNSAqNiA3IDEwIDExIDEyIDE0IDE1KQpBQ1BJOiBQQ0kgSW50ZXJydXB0
IExpbmsgW0xOS0RdIChJUlFzIDMgNCAqNSA2IDcgMTAgMTEgMTIgMTQgMTUp
CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRV0gKElSUXMgMyA0IDUg
NiA3IDEwIDExIDEyIDE0IDE1KSAqMCwgZGlzYWJsZWQuCkFDUEk6IFBDSSBJ
bnRlcnJ1cHQgTGluayBbTE5LRl0gKElSUXMgMyA0IDUgNiA3IDEwIDExIDEy
IDE0IDE1KSAqMCwgZGlzYWJsZWQuCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGlu
ayBbTE5LR10gKElSUXMgMyA0IDUgNiA3IDEwIDExIDEyIDE0IDE1KSAqMCwg
ZGlzYWJsZWQuCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LSF0gKElS
UXMgMyA0IDUgNiA3IDEwIDExIDEyIDE0ICoxNSkKTGludXggUGx1ZyBhbmQg
UGxheSBTdXBwb3J0IHYwLjk3IChjKSBBZGFtIEJlbGF5CnBucDogUG5QIEFD
UEkgaW5pdApwbnA6IFBuUCBBQ1BJOiBmb3VuZCAxNyBkZXZpY2VzClBuUEJJ
T1M6IERpc2FibGVkIGJ5IEFDUEkgUE5QClBDSTogVXNpbmcgQUNQSSBmb3Ig
SVJRIHJvdXRpbmcKUENJOiBJZiBhIGRldmljZSBkb2Vzbid0IHdvcmssIHRy
eSAicGNpPXJvdXRlaXJxIi4gIElmIGl0IGhlbHBzLCBwb3N0IGEgcmVwb3J0
CnBucDogMDA6MGI6IGlvcG9ydCByYW5nZSAweGEwMC0weGE3ZiBoYXMgYmVl
biByZXNlcnZlZApwbnA6IDAwOjBiOiBpb3BvcnQgcmFuZ2UgMHhhODAtMHhh
OGYgaGFzIGJlZW4gcmVzZXJ2ZWQKUENJOiBCcmlkZ2U6IDAwMDA6MDA6MWMu
MAogIElPIHdpbmRvdzogZGlzYWJsZWQuCiAgTUVNIHdpbmRvdzogZGlzYWJs
ZWQuCiAgUFJFRkVUQ0ggd2luZG93OiBkaXNhYmxlZC4KUENJOiBCcmlkZ2U6
IDAwMDA6MDA6MWMuNQogIElPIHdpbmRvdzogZGlzYWJsZWQuCiAgTUVNIHdp
bmRvdzogZmVhMDAwMDAtZmVhZmZmZmYKICBQUkVGRVRDSCB3aW5kb3c6IGRp
c2FibGVkLgpQQ0k6IEJyaWRnZTogMDAwMDowMDoxZS4wCiAgSU8gd2luZG93
OiBlMDAwLWVmZmYKICBNRU0gd2luZG93OiBmZWIwMDAwMC1mZWJmZmZmZgog
IFBSRUZFVENIIHdpbmRvdzogZTgwMDAwMDAtZWZmZmZmZmYKQUNQSTogUENJ
IEludGVycnVwdCAwMDAwOjAwOjFjLjBbQV0gLT4gR1NJIDE2IChsZXZlbCwg
bG93KSAtPiBJUlEgMTY5ClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9m
IGRldmljZSAwMDAwOjAwOjFjLjAgdG8gNjQKQUNQSTogUENJIEludGVycnVw
dCAwMDAwOjAwOjFjLjVbQl0gLT4gR1NJIDE3IChsZXZlbCwgbG93KSAtPiBJ
UlEgMTc3ClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAw
MDAwOjAwOjFjLjUgdG8gNjQKUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIg
b2YgZGV2aWNlIDAwMDA6MDA6MWUuMCB0byA2NApORVQ6IFJlZ2lzdGVyZWQg
cHJvdG9jb2wgZmFtaWx5IDIKSVAgcm91dGUgY2FjaGUgaGFzaCB0YWJsZSBl
bnRyaWVzOiAzMjc2OCAob3JkZXI6IDUsIDEzMTA3MiBieXRlcykKVENQIGVz
dGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjog
OCwgMTA0ODU3NiBieXRlcykKVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykKVENQOiBIYXNoIHRh
YmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAxMzEwNzIgYmluZCA2NTUz
NikKVENQIHJlbm8gcmVnaXN0ZXJlZAphdWRpdDogaW5pdGlhbGl6aW5nIG5l
dGxpbmsgc29ja2V0IChkaXNhYmxlZCkKYXVkaXQoMTE5MDAzNjMyOC4wNjQ6
MSk6IGluaXRpYWxpemVkCmhpZ2htZW0gYm91bmNlIHBvb2wgc2l6ZTogNjQg
cGFnZXMKVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMQpEcXVvdC1jYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEwMjQgKG9yZGVyIDAsIDQwOTYgYnl0
ZXMpCkluaXRpYWxpemluZyBDcnlwdG9ncmFwaGljIEFQSQppbyBzY2hlZHVs
ZXIgbm9vcCByZWdpc3RlcmVkCmlvIHNjaGVkdWxlciBhbnRpY2lwYXRvcnkg
cmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJlZApp
byBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQgKGRlZmF1bHQpClBDSTogU2V0
dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAwMDAwOjAwOjFjLjAgdG8g
NjQKYXNzaWduX2ludGVycnVwdF9tb2RlIEZvdW5kIE1TSSBjYXBhYmlsaXR5
CkFsbG9jYXRlIFBvcnQgU2VydmljZVswMDAwOjAwOjFjLjA6cGNpZTAwXQpB
bGxvY2F0ZSBQb3J0IFNlcnZpY2VbMDAwMDowMDoxYy4wOnBjaWUwMl0KUENJ
OiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWMu
NSB0byA2NAphc3NpZ25faW50ZXJydXB0X21vZGUgRm91bmQgTVNJIGNhcGFi
aWxpdHkKQWxsb2NhdGUgUG9ydCBTZXJ2aWNlWzAwMDA6MDA6MWMuNTpwY2ll
MDBdCkFsbG9jYXRlIFBvcnQgU2VydmljZVswMDAwOjAwOjFjLjU6cGNpZTAy
XQppc2FwbnA6IFNjYW5uaW5nIGZvciBQblAgY2FyZHMuLi4KaXNhcG5wOiBO
byBQbHVnICYgUGxheSBkZXZpY2UgZm91bmQKU2VyaWFsOiA4MjUwLzE2NTUw
IGRyaXZlciAkUmV2aXNpb246IDEuOTAgJCA0IHBvcnRzLCBJUlEgc2hhcmlu
ZyBlbmFibGVkCnNlcmlhbDgyNTA6IHR0eVMwIGF0IEkvTyAweDNmOCAoaXJx
ID0gNCkgaXMgYSAxNjU1MEEKc2VyaWFsODI1MDogdHR5UzEgYXQgSS9PIDB4
MmY4IChpcnEgPSAzKSBpcyBhIDE2NTUwQQowMDowODogdHR5UzAgYXQgSS9P
IDB4M2Y4IChpcnEgPSA0KSBpcyBhIDE2NTUwQQowMDowOTogdHR5UzEgYXQg
SS9PIDB4MmY4IChpcnEgPSAzKSBpcyBhIDE2NTUwQQpSQU1ESVNLIGRyaXZl
ciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDgxOTJLIHNpemUgMTAy
NCBibG9ja3NpemUKUE5QOiBQUy8yIENvbnRyb2xsZXIgW1BOUDAzMDM6UFMy
SyxQTlAwZjAzOlBTMk1dIGF0IDB4NjAsMHg2NCBpcnEgMSwxMgpzZXJpbzog
aTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMgpzZXJpbzogaTgw
NDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxCm1pY2U6IFBTLzIgbW91
c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UKVENQIGJpYyByZWdpc3Rl
cmVkCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQpORVQ6IFJl
Z2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3Ck5FVDogUmVnaXN0ZXJlZCBw
cm90b2NvbCBmYW1pbHkgOApORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFt
aWx5IDIwClN0YXJ0aW5nIGJhbGFuY2VkX2lycQpVc2luZyBJUEkgTm8tU2hv
cnRjdXQgbW9kZQpBQ1BJOiAoc3VwcG9ydHMgUzAgUzQgUzUpCkZyZWVpbmcg
dW51c2VkIGtlcm5lbCBtZW1vcnk6IDE5NmsgZnJlZWQKVGltZTogdHNjIGNs
b2Nrc291cmNlIGhhcyBiZWVuIGluc3RhbGxlZC4KaW5wdXQ6IEFUIFRyYW5z
bGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2NsYXNzL2lucHV0L2lucHV0MApB
Q1BJIEV4Y2VwdGlvbiAoYWNwaV9wcm9jZXNzb3ItMDY4MSk6IEFFX05PVF9G
T1VORCwgUHJvY2Vzc29yIERldmljZSBpcyBub3QgcHJlc2VudCBbMjAwNjA3
MDddCkFDUEk6IEdldHRpbmcgY3B1aW5kZXggZm9yIGFjcGlpZCAweDMKQUNQ
SSBFeGNlcHRpb24gKGFjcGlfcHJvY2Vzc29yLTA2ODEpOiBBRV9OT1RfRk9V
TkQsIFByb2Nlc3NvciBEZXZpY2UgaXMgbm90IHByZXNlbnQgWzIwMDYwNzA3
XQpBQ1BJOiBHZXR0aW5nIGNwdWluZGV4IGZvciBhY3BpaWQgMHg0CnVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciB1c2Jmcwp1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBkcml2ZXIgaHViClVTQiBVbml2ZXJzYWwgSG9zdCBDb250
cm9sbGVyIEludGVyZmFjZSBkcml2ZXIgdjMuMApBQ1BJOiBQQ0kgSW50ZXJy
dXB0IDAwMDA6MDA6MWQuMFtBXSAtPiBHU0kgMjMgKGxldmVsLCBsb3cpIC0+
IElSUSAyMDkKUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNl
IDAwMDA6MDA6MWQuMCB0byA2NAp1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IFVI
Q0kgSG9zdCBDb250cm9sbGVyCnVoY2lfaGNkIDAwMDA6MDA6MWQuMDogbmV3
IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxCnVo
Y2lfaGNkIDAwMDA6MDA6MWQuMDogaXJxIDIwOSwgaW8gYmFzZSAweDAwMDBk
YzAwCnVzYiB1c2IxOiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEg
Y2hvaWNlCmh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kCmh1YiAxLTA6MS4w
OiAyIHBvcnRzIGRldGVjdGVkClVuaWZvcm0gTXVsdGktUGxhdGZvcm0gRS1J
REUgZHJpdmVyIFJldmlzaW9uOiA3LjAwYWxwaGEyCmlkZTogQXNzdW1pbmcg
MzNNSHogc3lzdGVtIGJ1cyBzcGVlZCBmb3IgUElPIG1vZGVzOyBvdmVycmlk
ZSB3aXRoIGlkZWJ1cz14eApBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6MDA6
MWQuMVtCXSAtPiBHU0kgMTkgKGxldmVsLCBsb3cpIC0+IElSUSAyMTcKUENJ
OiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MWQu
MSB0byA2NAp1aGNpX2hjZCAwMDAwOjAwOjFkLjE6IFVIQ0kgSG9zdCBDb250
cm9sbGVyCnVoY2lfaGNkIDAwMDA6MDA6MWQuMTogbmV3IFVTQiBidXMgcmVn
aXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyCnVoY2lfaGNkIDAwMDA6
MDA6MWQuMTogaXJxIDIxNywgaW8gYmFzZSAweDAwMDBkODgwCnVzYiB1c2Iy
OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlCmh1YiAy
LTA6MS4wOiBVU0IgaHViIGZvdW5kCmh1YiAyLTA6MS4wOiAyIHBvcnRzIGRl
dGVjdGVkCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDoxZC4yW0NdIC0+
IEdTSSAxOCAobGV2ZWwsIGxvdykgLT4gSVJRIDIyNQpQQ0k6IFNldHRpbmcg
bGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDoxZC4yIHRvIDY0CnVo
Y2lfaGNkIDAwMDA6MDA6MWQuMjogVUhDSSBIb3N0IENvbnRyb2xsZXIKdWhj
aV9oY2QgMDAwMDowMDoxZC4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDMKdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBp
cnEgMjI1LCBpbyBiYXNlIDB4MDAwMGQ4MDAKdXNiIHVzYjM6IGNvbmZpZ3Vy
YXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UKaHViIDMtMDoxLjA6IFVT
QiBodWIgZm91bmQKaHViIDMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQKQUNQ
STogUENJIEludGVycnVwdCAwMDAwOjAwOjFkLjdbQV0gLT4gR1NJIDIzIChs
ZXZlbCwgbG93KSAtPiBJUlEgMjA5ClBDSTogU2V0dGluZyBsYXRlbmN5IHRp
bWVyIG9mIGRldmljZSAwMDAwOjAwOjFkLjcgdG8gNjQKZWhjaV9oY2QgMDAw
MDowMDoxZC43OiBFSENJIEhvc3QgQ29udHJvbGxlcgplaGNpX2hjZCAwMDAw
OjAwOjFkLjc6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1
cyBudW1iZXIgNAplaGNpX2hjZCAwMDAwOjAwOjFkLjc6IGRlYnVnIHBvcnQg
MQpQQ0k6IGNhY2hlIGxpbmUgc2l6ZSBvZiAxMjggaXMgbm90IHN1cHBvcnRl
ZCBieSBkZXZpY2UgMDAwMDowMDoxZC43CmVoY2lfaGNkIDAwMDA6MDA6MWQu
NzogaXJxIDIwOSwgaW8gbWVtIDB4ZmU5ZmZjMDAKZWhjaV9oY2QgMDAwMDow
MDoxZC43OiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMCwgZHJpdmVyIDEw
IERlYyAyMDA0CnVzYiB1c2I0OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBm
cm9tIDEgY2hvaWNlCmh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kCmh1YiA0
LTA6MS4wOiA2IHBvcnRzIGRldGVjdGVkCnRnMy5jOnYzLjY1IChBdWd1c3Qg
MDcsIDIwMDYpCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowNzowMC4wW0Fd
IC0+IEdTSSAxNyAobGV2ZWwsIGxvdykgLT4gSVJRIDE3NwpQQ0k6IFNldHRp
bmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowNzowMC4wIHRvIDY0
ClNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkCmV0aDA6IFRpZ29uMyBbcGFy
dG5vKEJDTTk1NzIxKSByZXYgNDEwMSBQSFkoNTc1MCldIChQQ0kgRXhwcmVz
cykgMTAvMTAwLzEwMDBCYXNlVCBFdGhlcm5ldCAwMDoxNzowODo1NDo5Yzow
ZgpldGgwOiBSWGNzdW1zWzFdIExpbmtDaGdSRUdbMF0gTUlpcnFbMF0gQVNG
WzFdIFNwbGl0WzBdIFdpcmVTcGVlZFsxXSBUU09jYXBbMV0gCmV0aDA6IGRt
YV9yd2N0cmxbNzYxODAwMDBdIGRtYV9tYXNrWzY0LWJpdF0KSUNINzogSURF
IGNvbnRyb2xsZXIgYXQgUENJIHNsb3QgMDAwMDowMDoxZi4xCmxpYmF0YSB2
ZXJzaW9uIDIuMDAgbG9hZGVkLgpBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6
MDA6MWYuMVtBXSAtPiBHU0kgMTggKGxldmVsLCBsb3cpIC0+IElSUSAyMjUK
SUNINzogY2hpcHNldCByZXZpc2lvbiAxCklDSDc6IG5vdCAxMDAlIG5hdGl2
ZSBtb2RlOiB3aWxsIHByb2JlIGlycXMgbGF0ZXIKICAgIGlkZTA6IEJNLURN
QSBhdCAweGZmYTAtMHhmZmE3LCBCSU9TIHNldHRpbmdzOiBoZGE6RE1BLCBo
ZGI6cGlvCiAgICBpZGUxOiBCTS1ETUEgYXQgMHhmZmE4LTB4ZmZhZiwgQklP
UyBzZXR0aW5nczogaGRjOnBpbywgaGRkOnBpbwpQcm9iaW5nIElERSBpbnRl
cmZhY2UgaWRlMC4uLgpoZGE6IEhMLURULVNUIENELVJPTSBHQ1ItODQ4NkIs
IEFUQVBJIENEL0RWRC1ST00gZHJpdmUKaWRlMCBhdCAweDFmMC0weDFmNyww
eDNmNiBvbiBpcnEgMTQKUHJvYmluZyBJREUgaW50ZXJmYWNlIGlkZTEuLi4K
YXRhX3BpaXggMDAwMDowMDoxZi4yOiB2ZXJzaW9uIDIuMDAKYXRhX3BpaXgg
MDAwMDowMDoxZi4yOiBNQVAgWyBQMCBQMiBQMSBQMyBdCkFDUEk6IFBDSSBJ
bnRlcnJ1cHQgMDAwMDowMDoxZi4yW0JdIC0+IEdTSSAxOSAobGV2ZWwsIGxv
dykgLT4gSVJRIDIxNwpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBk
ZXZpY2UgMDAwMDowMDoxZi4yIHRvIDY0CmF0YTE6IFNBVEEgbWF4IFVETUEv
MTMzIGNtZCAweEQ0ODAgY3RsIDB4RDQwMiBibWRtYSAweENDMDAgaXJxIDIx
NwphdGEyOiBTQVRBIG1heCBVRE1BLzEzMyBjbWQgMHhEMDgwIGN0bCAweEQw
MDIgYm1kbWEgMHhDQzA4IGlycSAyMTcKc2NzaTAgOiBhdGFfcGlpeApoZGE6
IEFUQVBJIDQ4WCBDRC1ST00gZHJpdmUsIDk2a0IgQ2FjaGUsIFVETUEoMzMp
ClVuaWZvcm0gQ0QtUk9NIGRyaXZlciBSZXZpc2lvbjogMy4yMAphdGExLjAw
OiBBVEEtNywgbWF4IFVETUEvMTAwLCAxNTYzMDE0ODggc2VjdG9yczogTEJB
NDggCmF0YTEuMDA6IGF0YTE6IGRldiAwIG11bHRpIGNvdW50IDE2CmF0YTEu
MDA6IGNvbmZpZ3VyZWQgZm9yIFVETUEvMTAwCnNjc2kxIDogYXRhX3BpaXgK
QVRBOiBhYm5vcm1hbCBzdGF0dXMgMHg3RiBvbiBwb3J0IDB4RDA4NwogIFZl
bmRvcjogQVRBICAgICAgIE1vZGVsOiBNYXh0b3IgNkwwODBNMCAgICBSZXY6
IEJBQ0UKICBUeXBlOiAgIERpcmVjdC1BY2Nlc3MgICAgICAgICAgICAgICAg
ICAgICAgQU5TSSBTQ1NJIHJldmlzaW9uOiAwNQpTQ1NJIGRldmljZSBzZGE6
IDE1NjMwMTQ4OCA1MTItYnl0ZSBoZHdyIHNlY3RvcnMgKDgwMDI2IE1CKQpz
ZGE6IFdyaXRlIFByb3RlY3QgaXMgb2ZmCnNkYTogTW9kZSBTZW5zZTogMDAg
M2EgMDAgMDAKU0NTSSBkZXZpY2Ugc2RhOiBkcml2ZSBjYWNoZTogd3JpdGUg
dGhyb3VnaApTQ1NJIGRldmljZSBzZGE6IDE1NjMwMTQ4OCA1MTItYnl0ZSBo
ZHdyIHNlY3RvcnMgKDgwMDI2IE1CKQpzZGE6IFdyaXRlIFByb3RlY3QgaXMg
b2ZmCnNkYTogTW9kZSBTZW5zZTogMDAgM2EgMDAgMDAKU0NTSSBkZXZpY2Ug
c2RhOiBkcml2ZSBjYWNoZTogd3JpdGUgdGhyb3VnaAogc2RhOiBzZGExIHNk
YTIKc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBkaXNrIHNkYQpBdHRlbXB0
aW5nIG1hbnVhbCByZXN1bWUKa2pvdXJuYWxkIHN0YXJ0aW5nLiAgQ29tbWl0
IGludGVydmFsIDUgc2Vjb25kcwpFWFQzLWZzOiBtb3VudGVkIGZpbGVzeXN0
ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4KaW50ZWxfcm5nOiBGV0ggbm90
IGRldGVjdGVkCmlucHV0OiBQQyBTcGVha2VyIGFzIC9jbGFzcy9pbnB1dC9p
bnB1dDEKUmVhbCBUaW1lIENsb2NrIERyaXZlciB2MS4xMmFjCnBhcnBvcnQ6
IFBuUEJJT1MgcGFycG9ydCBkZXRlY3RlZC4KcGFycG9ydDA6IFBDLXN0eWxl
IGF0IDB4Mzc4ICgweDc3OCksIGlycSA3LCBkbWEgMyBbUENTUFAsVFJJU1RB
VEUsQ09NUEFULEVDUCxETUFdCmlucHV0OiBJbVBTLzIgR2VuZXJpYyBXaGVl
bCBNb3VzZSBhcyAvY2xhc3MvaW5wdXQvaW5wdXQyCnRzOiBDb21wYXEgdG91
Y2hzY3JlZW4gcHJvdG9jb2wgb3V0cHV0CkFkZGluZyA3ODE1NTgwayBzd2Fw
IG9uIC9kZXYvc2RhMS4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MSBhY3Jvc3M6
NzgxNTU4MGsKRVhUMyBGUyBvbiBzZGEyLCBpbnRlcm5hbCBqb3VybmFsCmxv
b3A6IGxvYWRlZCAobWF4IDggZGV2aWNlcykKZGV2aWNlLW1hcHBlcjogaW9j
dGw6IDQuNy4wLWlvY3RsICgyMDA2LTA2LTI0KSBpbml0aWFsaXNlZDogZG0t
ZGV2ZWxAcmVkaGF0LmNvbQpQTTogV3JpdGluZyBiYWNrIGNvbmZpZyBzcGFj
ZSBvbiBkZXZpY2UgMDAwMDowNzowMC4wIGF0IG9mZnNldCBjICh3YXMgMTc4
MjAwMDAsIHdyaXRpbmcgMCkK

--0-1434099264-1190231563=:18461--



From scott.marlowe@gmail.com Wed Sep  19 20:15:54 2007
Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id A87FC9F9B95
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 17:15:54 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 78715-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 19 Sep 2007 17:15:40 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170])
	by postgresql.org (Postfix) with ESMTP id EC1A69F9431
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 17:15:38 -0300 (ADT)
Received: by ug-out-1314.google.com with SMTP id j3so318915ugf
	for <pgsql-performance@postgresql.org>;
	Wed, 19 Sep 2007 13:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	bh=3dNCYvYSk8Ypd10gaRfqRdq29ip67mEoyuOGZObioJU=;
	b=fw0BXedkEVTAgS3auJhanZQHcQ+6GIctOPA9/LFUAV7ILF6VbsXithcl8KFGGzxwDLIa83mJtwTriSXJTXhTNYILd70yhhRytFId8VPMDUsb2k0tsCsH0jGQhOQvOKl5LxQmXEM5joEdOnhTBfH5fgMUFfQa477k9/iOeRs0SNU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=XdnsWTaWMT5R3m/GvYkQiv/3tn5lLGQb99Ve/dNNcSbnHGXghZSh+nWV4LXPDHRzSG/vMraseCdo/DeZgcVX68aWM2HWr7ZtE2BJsr1w8Liar4W6LhkwkKL3Rs1drUQTxBfUNoNFmVghP+5pkgcbbbmOgzrjfBkZgwNh97dAcNw=
Received: by 10.67.16.5 with SMTP id t5mr2324197ugi.1190232934164;
	Wed, 19 Sep 2007 13:15:34 -0700 (PDT)
Received: by 10.66.220.7 with HTTP; Wed, 19 Sep 2007 13:15:34 -0700 (PDT)
Message-ID: <dcc563d10709191315u34115ef1r47d7320ddb22714c@mail.gmail.com>
Date: Wed, 19 Sep 2007 15:15:34 -0500
From: "Scott Marlowe" <scott.marlowe@gmail.com>
To: "brauagustin-susc@yahoo.com.ar" <brauagustin-susc@yahoo.com.ar>
Subject: Re: Low CPU Usage
Cc: pgsql-performance@postgresql.org
In-Reply-To: <27902.18461.qm@web30003.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <27902.18461.qm@web30003.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/324
X-Sequence-Number: 26869

On 9/19/07, brauagustin-susc@yahoo.com.ar <brauagustin-susc@yahoo.com.ar> wrote:
>
> This is my dmesg file, I see there are some errors but I don't know how to
> manage!!!

nothing too horrible.  Just wanted to make sure you weren't getting
lots of bad sectors or timeouts.

Nothing too bad looking there.

> What do you mean with don't top post?

It means when you put your post at the top of mine.  The way I'm
answering provides context.  I.e. this paragraph I'm writing goes with
the paragraph you wrote that I'm answering.  It makes it easier to
keep track of long busy conversations.

> Sorry but I'm new with this kind of mailing list and I don't want to botter
> some others.
> Sorry my bad English too.

No bother, and your english is way better than my Spanish.  or
Russian, or Japanese, etc...



From brauagustin-susc@yahoo.com.ar Thu Sep  20 11:31:07 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 1486B9F9B27
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 08:31:07 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 46481-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 08:30:50 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30010.mail.mud.yahoo.com (web30010.mail.mud.yahoo.com
	[209.191.69.27]) by postgresql.org (Postfix) with SMTP id CEF459F9B04
	for <pgsql-performance@postgresql.org>;
	Thu, 20 Sep 2007 08:30:54 -0300 (ADT)
Received: (qmail 58169 invoked by uid 60001); 20 Sep 2007 11:30:53 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=jB92uVvrwIr2T33f2mB6qkB4LbYX2aljGK1iSm87ilSGjORB7EwuZgGr/z8Y4pTdto7p7I5FfZhTyzP5+7brniXRpCMLjqJDGzyPa+fmiwiOEHsgPGy39pLUgBGK4djdW7RqmmxIq25lpEAOBgJPTGF6ao726j7Apkdk5RSue0I=;
X-YMail-OSG: 
 Yhw_4h4VM1mx2PPo6tzps0wAJd6KarC7w6Wy_4a99kenfaA1l9yHzeVm7YiCWMnDjU4Y3BJf3YFkIIXeR90jAez6NXg9PEitVj4s9DLV_sX_AEPTAKzpVLcU3UJEQw--
Received: from [68.142.201.145] by web30010.mail.mud.yahoo.com via HTTP;
	Thu, 20 Sep 2007 04:30:53 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Thu, 20 Sep 2007 04:30:53 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Norberto Meijome <beto@octantis.com.au>
Cc: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1393920195-1190287853=:56511"
Message-ID: <311295.56511.qm@web30010.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.002 tagged_above=0 required=5 tests=BAYES_50=0.001,
	HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200709/327
X-Sequence-Number: 26872

--0-1393920195-1190287853=:56511
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hola Beto.=0AI have no idea where to look for that configuration or setting=
s.=0AYesterday I red about some drivers problems with SATA disk working tog=
heter with IDE devices with DMA.=0A=0AMi server server is a Pentium VI 3.3 =
with hyper threading (enabled in BIOS), HP Proliant ML 110.=0A=0AThen I ent=
ered to the BIOS and saw in IDE Configuration: =0A  ATA/IDE Configuration  =
                  [Enhanced]=0A          Configure SATA as                 =
  [IDE]  =3D> it has RAID option too=0A=0AI have any idea how to continue!!=
! I don't know if this a SATA problem, a configuration problem or what else=
. I have installed several servers beggining with postgres 6.4 and I've nev=
ed had this kind of problems (always with IDE disks). I think this is a pro=
blem with SATA disk i/o, but I don't see how to measure that (I have alread=
y set postgresql.conf).=0A=0ARegards=0AAgustin=0A=0A=0A----- Mensaje origin=
al ----=0ADe: Norberto Meijome <beto@octantis.com.au>=0APara: brauagustin-s=
usc@yahoo.com.ar=0ACC: pgsql-performance@postgresql.org=0AEnviado: jueves 2=
0 de septiembre de 2007, 7:53:05=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=
=0AOn Wed, 19 Sep 2007 12:13:33 -0700 (PDT)=0Abrauagustin-susc@yahoo.com.ar=
 wrote:=0A=0A> max_stack_depth =3D 7MB #in the old server is 8MB but if I s=
et in here give me the ulimit error=0A=0AHola Agustin :)=0Aotro argentino e=
n el extranjero x aca ;) =0A=0Aanyway, back to English ;)=0A=0Aa long shot =
but...=0A=0Acheck if you have any limits set on the host for CPU usage... y=
ou may be=0Alimited to x number of secs / % by the OS scheduler. When you q=
uery your CPU,=0Ait will say u are only using 5% or so... =0A=0Achau,=0ABet=
o=0A=0A_________________________=0ANorberto Meijome=0AOctantis Pty Ltd=0A=
=0AIntelligence: Finding an error in a Knuth text.=0AStupidity: Cashing tha=
t $2.56 check you got.=0A=0A=0A=0A=0ANOTICE: The contents of this email and=
 its attachments are confidential and=0Aintended only for the individuals o=
r entities named above. If you have received=0Athis message in error, pleas=
e advise the sender by reply email and immediately=0Adelete the message and=
 any attachments without using, copying or disclosing the=0Acontents. Thank=
 you.=0A=0A=0A=0A=0A=0A=0A=0A      Los referentes m=E1s importantes en comp=
ra/ venta de autos se juntaron:=0ADemotores y Yahoo!=0AAhora comprar o vend=
er tu auto es m=E1s f=E1cil. Vist=E1 ar.autos.yahoo.com/
--0-1393920195-1190287853=:56511
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">Hola Beto.<br>I have no idea where to look for that=
 configuration or settings.<br>Yesterday I red about some drivers problems =
with SATA disk working togheter with IDE devices with DMA.<br><br>Mi server=
 server is a Pentium VI 3.3 with hyper threading (enabled in BIOS), HP Prol=
iant ML 110.<br><br>Then I entered to the BIOS and saw in IDE Configuration=
: <br>&nbsp; ATA/IDE Configuration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=
Enhanced]<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Configu=
re SATA as&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [IDE]&nbsp; =3D&gt; it has RAID
 option too<br><br>I have any idea how to continue!!! I don't know if this =
a SATA problem, a configuration problem or what else. I have installed seve=
ral servers beggining with postgres 6.4 and I've neved had this kind of pro=
blems (always with IDE disks). I think this is a problem with SATA disk i/o=
, but I don't see how to measure that (I have already set postgresql.conf).=
<br><br>Regards<br>Agustin<br><br><br><div style=3D"font-family: times new =
roman,new york,times,serif; font-size: 12pt;">----- Mensaje original ----<b=
r>De: Norberto Meijome &lt;beto@octantis.com.au&gt;<br>Para: brauagustin-su=
sc@yahoo.com.ar<br>CC: pgsql-performance@postgresql.org<br>Enviado: jueves =
20 de septiembre de 2007, 7:53:05<br>Asunto: Re: [PERFORM] Low CPU Usage<br=
><br><div>On Wed, 19 Sep 2007 12:13:33 -0700 (PDT)<br>brauagustin-susc@yaho=
o.com.ar wrote:<br><br>&gt; max_stack_depth =3D 7MB #in the old server is 8=
MB but if I set in here give me the ulimit error<br><br>Hola Agustin
 :)<br>otro argentino en el extranjero x aca ;) <br><br>anyway, back to Eng=
lish ;)<br><br>a long shot but...<br><br>check if you have any limits set o=
n the host for CPU usage... you may be<br>limited to x number of secs / % b=
y the OS scheduler. When you query your CPU,<br>it will say u are only usin=
g 5% or so... <br><br>chau,<br>Beto<br><br>_________________________<br>Nor=
berto Meijome<br>Octantis Pty Ltd<br><br>Intelligence: Finding an error in =
a Knuth text.<br>Stupidity: Cashing that $2.56 check you got.<br><br><br><b=
r><br>NOTICE: The contents of this email and its attachments are confidenti=
al and<br>intended only for the individuals or entities named above. If you=
 have received<br>this message in error, please advise the sender by reply =
email and immediately<br>delete the message and any attachments without usi=
ng, copying or disclosing the<br>contents. Thank you.<br></div></div><br></=
div></div><br>=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"-2">=
El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deportes:<br>=
=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></html>
--0-1393920195-1190287853=:56511--



From jeandavid8@verizon.net Thu Sep  20 12:32:22 2007
Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 7DA2F9F9B23
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 09:32:22 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 47052-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 09:31:42 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44])
	by postgresql.org (Postfix) with ESMTP id E22479F9AC8
	for <pgsql-performance@postgresql.org>;
	Thu, 20 Sep 2007 09:31:42 -0300 (ADT)
Received: from [192.168.0.251] ([71.251.196.74])
	by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01
	(built Apr
	3 2006)) with ESMTPA id <0JOO00K432SOGNF3@vms044.mailsrvcs.net> for
	pgsql-performance@postgresql.org; Thu, 20 Sep 2007 07:31:38 -0500 (CDT)
Date: Thu, 20 Sep 2007 08:31:36 -0400
From: Jean-David Beyer <jeandavid8@verizon.net>
Subject: Re: Low CPU Usage
In-reply-to: <311295.56511.qm@web30010.mail.mud.yahoo.com>
To: pgsql-performance@postgresql.org
Message-id: <46F26828.3060001@verizon.net>
Organization: Institute for Regimented Whimsey
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
X-Enigmail-Version: 0.94.0.0
References: <311295.56511.qm@web30010.mail.mud.yahoo.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070317)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/328
X-Sequence-Number: 26873

brauagustin-susc@yahoo.com.ar wrote:
> Hola Beto.
> I have no idea where to look for that configuration or settings.

In postgreSQL, the main settings are in .../pgsql/data/postgresql.conf

> Yesterday I red about some drivers problems with SATA disk working
> togheter with IDE devices with DMA.
> 
> Mi server server is a Pentium VI 3.3 with hyper threading (enabled in
> BIOS), HP Proliant ML 110.
> 
> Then I entered to the BIOS and saw in IDE Configuration:
>   ATA/IDE Configuration                    [Enhanced]
>           Configure SATA as                   [IDE]  => it has RAID
> option too
> 
> I have any idea how to continue!!! I don't know if this a SATA problem,
> a configuration problem or what else. I have installed several servers
> beggining with postgres 6.4 and I've neved had this kind of problems
> (always with IDE disks). I think this is a problem with SATA disk i/o,
> but I don't see how to measure that (I have already set postgresql.conf).

Are you sure you are really having a problem with insufficient CPU time
being devoted to your program(s)? When I run postgreSQL and do the initial
populating of my database, which takes several hours due to the nature of
the input data, it runs just 25% to 50% of one CPU, even though I have two
3.06 GHz hyperthreaded Xeon processors and six 10,000 rpm Ultra/320 SCSI
hard drives on two SCSI controllers. If I look at the results of the Linux
top command, and iostat and vmstat, I see that I am in io-wait state 100% of
the time. The transfer rate to the hard drives averages about 2
Megabytes/second even though I have seen 90 Megabytes/second at times (when
doing a database restore). So the IO system can be quite fast when it is not
waiting (for seeks, no doubt). If the postgreSQL processes wanted more CPU
time, they could have it as the machine does not do much else most of the
time. Actually, it runs a four BOINC processes, but they run at nice level
19, so they run only if no other process wants processing time. When I do a
database backup, it will run more than 100% of a CPU (remember I have two or
four processors, depending on how you count them) for extended periods, so
the OS is certainly capable of supplying CPU power when I need it. And
postgreSQL runs multiple processes at once, so in theory, they could gert
400% of a processor if they needed it. They do not seem to need to do this
for me.
> 
> Regards
> Agustin
> 
> 
> ----- Mensaje original ----
> De: Norberto Meijome <beto@octantis.com.au>
> Para: brauagustin-susc@yahoo.com.ar
> CC: pgsql-performance@postgresql.org
> Enviado: jueves 20 de septiembre de 2007, 7:53:05
> Asunto: Re: [PERFORM] Low CPU Usage
> 
> On Wed, 19 Sep 2007 12:13:33 -0700 (PDT)
> brauagustin-susc@yahoo.com.ar wrote:
> 
>> max_stack_depth = 7MB #in the old server is 8MB but if I set in here
> give me the ulimit error
> 
> Hola Agustin :)
> otro argentino en el extranjero x aca ;)
> 
> anyway, back to English ;)
> 
> a long shot but...
> 
> check if you have any limits set on the host for CPU usage... you may be
> limited to x number of secs / % by the OS scheduler. When you query your
> CPU,
> it will say u are only using 5% or so...
> 


-- 
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 08:15:01 up 6 days, 42 min, 1 user, load average: 4.24, 4.25, 4.14



From brauagustin-susc@yahoo.com.ar Thu Sep  20 17:28:44 2007
Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 95BA69F9862
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 14:28:44 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 20050-08 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 20 Sep 2007 14:28:40 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30009.mail.mud.yahoo.com (web30009.mail.mud.yahoo.com
	[209.191.69.26]) by postgresql.org (Postfix) with SMTP id DB8639F9B90
	for <pgsql-performance@postgresql.org>;
	Thu, 20 Sep 2007 14:28:39 -0300 (ADT)
Received: (qmail 77591 invoked by uid 60001); 20 Sep 2007 17:28:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=Su2I+Qg1cEBaRecuNL7nMgVVUwTTP15poss2UZBeoF90XFboXAYUzn2WN89jLmKUq+3nJkEa8yEG61l0F8OShpYdHm6NYuvR8PM8hImwI8TAA0sNjODpz1xJG1Fo+IigYOU9jKRGzEaTYDBnBcaAwsVUTWzgpyKdV3hAEtOP3Vg=;
X-YMail-OSG: 
 2mc5DqwVM1lVZWvl6dDoTGqXqSfKvzKVC03hj.Sofy6LyhTZCOHnGN8.RXWrHrVUMNZECrNiPDAInPH8CMR_CeNhEyuRhbfAMzjLytaW2BZdPfiZ.OOQIqhWFjeTfA--
Received: from [68.142.201.143] by web30009.mail.mud.yahoo.com via HTTP;
	Thu, 20 Sep 2007 10:28:37 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Thu, 20 Sep 2007 10:28:37 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Jean-David Beyer <jeandavid8@verizon.net>,
 pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1016616190-1190309317=:67716"
Message-ID: <383851.67716.qm@web30009.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/332
X-Sequence-Number: 26877

--0-1016616190-1190309317=:67716
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

My new server postgresql.conf is equal to the old one. I'm doubting this is=
 a hardware issue.=0AGoogling with my hard HP Proliant ML 110 G3 I saw that=
 IHC7 controller has some problems, but looking and testing with hdparm it =
looks ok.=0Ahdparm -tT /dev/sda=E7=0ATiming cached reads: 1722 MB in 2.00 s=
econds =3D 860.38 MB/sec=0ATiming buffered disks reads: 164 MB in 3.01 seco=
nds =3D 54.53 MB/sec=0A=0ADoing hdparm -I /dev/sda=0ADMA has * in udma5=0AW=
hich other test can I do to find if this is a hardware, kernel o postgres i=
ssue?=0A=0ARegards=0AAgustin=0A=0A----- Mensaje original ----=0ADe: Jean-Da=
vid Beyer <jeandavid8@verizon.net>=0APara: pgsql-performance@postgresql.org=
=0AEnviado: jueves 20 de septiembre de 2007, 9:31:36=0AAsunto: Re: [PERFORM=
] Low CPU Usage=0A=0Abrauagustin-susc@yahoo.com.ar wrote:=0A> Hola Beto.=0A=
> I have no idea where to look for that configuration or settings.=0A=0AIn =
postgreSQL, the main settings are in .../pgsql/data/postgresql.conf=0A=0A> =
Yesterday I red about some drivers problems with SATA disk working=0A> togh=
eter with IDE devices with DMA.=0A> =0A> Mi server server is a Pentium VI 3=
.3 with hyper threading (enabled in=0A> BIOS), HP Proliant ML 110.=0A> =0A>=
 Then I entered to the BIOS and saw in IDE Configuration:=0A>   ATA/IDE Con=
figuration                    [Enhanced]=0A>           Configure SATA as   =
                [IDE]  =3D> it has RAID=0A> option too=0A> =0A> I have any =
idea how to continue!!! I don't know if this a SATA problem,=0A> a configur=
ation problem or what else. I have installed several servers=0A> beggining =
with postgres 6.4 and I've neved had this kind of problems=0A> (always with=
 IDE disks). I think this is a problem with SATA disk i/o,=0A> but I don't =
see how to measure that (I have already set postgresql.conf).=0A=0AAre you =
sure you are really having a problem with insufficient CPU time=0Abeing dev=
oted to your program(s)? When I run postgreSQL and do the initial=0Apopulat=
ing of my database, which takes several hours due to the nature of=0Athe in=
put data, it runs just 25% to 50% of one CPU, even though I have two=0A3.06=
 GHz hyperthreaded Xeon processors and six 10,000 rpm Ultra/320 SCSI=0Ahard=
 drives on two SCSI controllers. If I look at the results of the Linux=0Ato=
p command, and iostat and vmstat, I see that I am in io-wait state 100% of=
=0Athe time. The transfer rate to the hard drives averages about 2=0AMegaby=
tes/second even though I have seen 90 Megabytes/second at times (when=0Adoi=
ng a database restore). So the IO system can be quite fast when it is not=
=0Awaiting (for seeks, no doubt). If the postgreSQL processes wanted more C=
PU=0Atime, they could have it as the machine does not do much else most of =
the=0Atime. Actually, it runs a four BOINC processes, but they run at nice =
level=0A19, so they run only if no other process wants processing time. Whe=
n I do a=0Adatabase backup, it will run more than 100% of a CPU (remember I=
 have two or=0Afour processors, depending on how you count them) for extend=
ed periods, so=0Athe OS is certainly capable of supplying CPU power when I =
need it. And=0ApostgreSQL runs multiple processes at once, so in theory, th=
ey could gert=0A400% of a processor if they needed it. They do not seem to =
need to do this=0Afor me.=0A> =0A> Regards=0A> Agustin=0A> =0A> =0A> ----- =
Mensaje original ----=0A> De: Norberto Meijome <beto@octantis.com.au>=0A> P=
ara: brauagustin-susc@yahoo.com.ar=0A> CC: pgsql-performance@postgresql.org=
=0A> Enviado: jueves 20 de septiembre de 2007, 7:53:05=0A> Asunto: Re: [PER=
FORM] Low CPU Usage=0A> =0A> On Wed, 19 Sep 2007 12:13:33 -0700 (PDT)=0A> b=
rauagustin-susc@yahoo.com.ar wrote:=0A> =0A>> max_stack_depth =3D 7MB #in t=
he old server is 8MB but if I set in here=0A> give me the ulimit error=0A> =
=0A> Hola Agustin :)=0A> otro argentino en el extranjero x aca ;)=0A> =0A> =
anyway, back to English ;)=0A> =0A> a long shot but...=0A> =0A> check if yo=
u have any limits set on the host for CPU usage... you may be=0A> limited t=
o x number of secs / % by the OS scheduler. When you query your=0A> CPU,=0A=
> it will say u are only using 5% or so...=0A> =0A=0A=0A-- =0A  .~.  Jean-D=
avid Beyer          Registered Linux User 85642.=0A  /V\  PGP-Key: 9A2FC99A=
         Registered Machine   241939.=0A /( )\ Shrewsbury, New Jersey    ht=
tp://counter.li.org=0A ^^-^^ 08:15:01 up 6 days, 42 min, 1 user, load avera=
ge: 4.24, 4.25, 4.14=0A=0A---------------------------(end of broadcast)----=
-----------------------=0ATIP 3: Have you checked our extensive FAQ?=0A=0A =
              http://www.postgresql.org/docs/faq=0A=0A=0A=0A=0A=0A=0A=0A   =
   Segu=ED de cerca a la Selecci=F3n Argentina de Rugby en el Mundial de Fr=
ancia 2007.=0Ahttp://ar.sports.yahoo.com/mundialderugby
--0-1016616190-1190309317=:67716
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">My new server postgresql.conf is equal to the old o=
ne. I'm doubting this is a hardware issue.<br>Googling with my hard HP Prol=
iant ML 110 G3 I saw that IHC7 controller has some problems, but looking an=
d testing with hdparm it looks ok.<br>hdparm -tT /dev/sda=E7<br>Timing cach=
ed reads: 1722 MB in 2.00 seconds =3D 860.38 MB/sec<br>Timing buffered disk=
s reads: 164 MB in 3.01 seconds =3D 54.53 MB/sec<br><br>Doing hdparm -I /de=
v/sda<br>DMA has * in udma5<br>Which other test can I do to find if this is=
 a hardware, kernel o postgres issue?<br><br>Regards<br>Agustin<br><br><div=
 style=3D"font-family: times new roman,new york,times,serif; font-size: 12p=
t;">----- Mensaje original ----<br>De: Jean-David Beyer
 &lt;jeandavid8@verizon.net&gt;<br>Para: pgsql-performance@postgresql.org<b=
r>Enviado: jueves 20 de septiembre de 2007, 9:31:36<br>Asunto: Re: [PERFORM=
] Low CPU Usage<br><br><div>brauagustin-susc@yahoo.com.ar wrote:<br>&gt; Ho=
la Beto.<br>&gt; I have no idea where to look for that configuration or set=
tings.<br><br>In postgreSQL, the main settings are in .../pgsql/data/postgr=
esql.conf<br><br>&gt; Yesterday I red about some drivers problems with SATA=
 disk working<br>&gt; togheter with IDE devices with DMA.<br>&gt; <br>&gt; =
Mi server server is a Pentium VI 3.3 with hyper threading (enabled in<br>&g=
t; BIOS), HP Proliant ML 110.<br>&gt; <br>&gt; Then I entered to the BIOS a=
nd saw in IDE Configuration:<br>&gt;&nbsp;&nbsp; ATA/IDE Configuration&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[Enhanced]<br>&gt;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Configure SATA
 as&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [IDE]&nbsp;&nbsp;=3D&gt; it has RAID<b=
r>&gt; option too<br>&gt; <br>&gt; I have any idea how to continue!!! I don=
't know if this a SATA problem,<br>&gt; a configuration problem or what els=
e. I have installed several servers<br>&gt; beggining with postgres 6.4 and=
 I've neved had this kind of problems<br>&gt; (always with IDE disks). I th=
ink this is a problem with SATA disk i/o,<br>&gt; but I don't see how to me=
asure that (I have already set postgresql.conf).<br><br>Are you sure you ar=
e really having a problem with insufficient CPU time<br>being devoted to yo=
ur program(s)? When I run postgreSQL and do the initial<br>populating of my=
 database, which takes several hours due to the nature of<br>the input data=
, it runs just 25% to 50% of one CPU, even though I have two<br>3.06 GHz hy=
perthreaded Xeon processors and six 10,000 rpm Ultra/320 SCSI<br>hard
 drives on two SCSI controllers. If I look at the results of the Linux<br>t=
op command, and iostat and vmstat, I see that I am in io-wait state 100% of=
<br>the time. The transfer rate to the hard drives averages about 2<br>Mega=
bytes/second even though I have seen 90 Megabytes/second at times (when<br>=
doing a database restore). So the IO system can be quite fast when it is no=
t<br>waiting (for seeks, no doubt). If the postgreSQL processes wanted more=
 CPU<br>time, they could have it as the machine does not do much else most =
of the<br>time. Actually, it runs a four BOINC processes, but they run at n=
ice level<br>19, so they run only if no other process wants processing time=
. When I do a<br>database backup, it will run more than 100% of a CPU (reme=
mber I have two or<br>four processors, depending on how you count them) for=
 extended periods, so<br>the OS is certainly capable of supplying CPU power=
 when I need it. And<br>postgreSQL runs multiple processes at once,
 so in theory, they could gert<br>400% of a processor if they needed it. Th=
ey do not seem to need to do this<br>for me.<br>&gt; <br>&gt; Regards<br>&g=
t; Agustin<br>&gt; <br>&gt; <br>&gt; ----- Mensaje original ----<br>&gt; De=
: Norberto Meijome &lt;beto@octantis.com.au&gt;<br>&gt; Para: brauagustin-s=
usc@yahoo.com.ar<br>&gt; CC: pgsql-performance@postgresql.org<br>&gt; Envia=
do: jueves 20 de septiembre de 2007, 7:53:05<br>&gt; Asunto: Re: [PERFORM] =
Low CPU Usage<br>&gt; <br>&gt; On Wed, 19 Sep 2007 12:13:33 -0700 (PDT)<br>=
&gt; brauagustin-susc@yahoo.com.ar wrote:<br>&gt; <br>&gt;&gt; max_stack_de=
pth =3D 7MB #in the old server is 8MB but if I set in here<br>&gt; give me =
the ulimit error<br>&gt; <br>&gt; Hola Agustin :)<br>&gt; otro argentino en=
 el extranjero x aca ;)<br>&gt; <br>&gt; anyway, back to English ;)<br>&gt;=
 <br>&gt; a long shot but...<br>&gt; <br>&gt; check if you have any limits =
set on the host for CPU usage... you may be<br>&gt; limited to x
 number of secs / % by the OS scheduler. When you query your<br>&gt; CPU,<b=
r>&gt; it will say u are only using 5% or so...<br>&gt; <br><br><br>-- <br>=
&nbsp;&nbsp;.~.&nbsp;&nbsp;Jean-David Beyer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;Registered Linux User 85642.<br>&nbsp;&nbsp;/V\=
&nbsp;&nbsp;PGP-Key: 9A2FC99A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Registered Machine&nbsp;&nbsp; 241939.<br> /( )\ Shrewsbury, New Jersey&=
nbsp;&nbsp;&nbsp;&nbsp;<a target=3D"_blank" href=3D"http://counter.li.org">=
http://counter.li.org</a><br> ^^-^^ 08:15:01 up 6 days, 42 min, 1 user, loa=
d average: 4.24, 4.25, 4.14<br><br>---------------------------(end of broad=
cast)---------------------------<br>TIP 3: Have you checked our extensive F=
AQ?<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <a target=3D"_blank"
 href=3D"http://www.postgresql.org/docs/faq">http://www.postgresql.org/docs=
/faq</a><br></div></div><br></div></div><br>=0A=0A=0A=0A      <hr size=3D1>=
<br><font face=3D"Verdana" size=3D"-2">Los referentes m=E1s importantes en =
compra/venta de autos se juntaron:<br>Demotores y Yahoo!.=0AAhora comprar o=
 vender tu auto es m=E1s f=E1cil. <br> Visit=E1 http://ar.autos.yahoo.com/<=
/font></body></html>
--0-1016616190-1190309317=:67716--



From brauagustin-susc@yahoo.com.ar Fri Sep  21 17:30:55 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 2BF909FA465
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:30:55 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 95828-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:30:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30006.mail.mud.yahoo.com (web30006.mail.mud.yahoo.com
	[209.191.69.23]) by postgresql.org (Postfix) with SMTP id DE0B69F9A42
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 14:30:47 -0300 (ADT)
Received: (qmail 57678 invoked by uid 60001); 21 Sep 2007 17:30:46 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=bERvvGcsYGcSH6PX9ypBQ1j1ACMidzuYWWbGwpxvs9fncoXYRe6vPG/yjlDOOK6al1vOP8K5bAlR5uNQrNIzQY50n/49R1zTinik1+q6zMb02Iy7PA0XOBVFzktv+IIvtZ6K4VXC5G5B+5eLn7sfNAbW2cQ5/hew0c1vYC8yIh4=;
X-YMail-OSG: 
 0yfNB54VM1lIdCz5pFgxb79TmlOEbM5LuFU2uVgAqQGJRyW4Cjqqjfz6QBb9XAT8YbhCSJCFm_BcXvSYge4CYO50quZjHtUJpAKUCbNSpQ703tjnfcB4EPCYDZpqqg--
Received: from [68.142.201.143] by web30006.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 10:30:45 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 10:30:45 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1748347442-1190395845=:47531"
Message-ID: <121711.47531.qm@web30006.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/372
X-Sequence-Number: 26917

--0-1748347442-1190395845=:47531
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I'm doing several tests.=0ARight now I did a VACUUM FULL ANALYZE in both se=
rvers.=0AIn the old one vacuum runs for about 354 seconds and in the new on=
e 59 seconds.=0A=0AThen I have ran=0AEXPLAIN ANALYZE=0ASELECT *=0AFROM fact=
_ven_renta fvr, dim_producto_std_producto dpp=0AWHERE=0A  fvr.producto_std_=
producto_sk =3D dpp.producto_sk=0A=0AI have found that the plans aren't exa=
ctly the same.=0AThis is the plan for the old server:=0AHash Join  (cost=3D=
449.55..8879.24 rows=3D136316 width=3D904) (actual time=3D50.734..1632.491 =
rows=3D136316 loops=3D1)=0A  Hash Cond: (fvr.producto_std_producto_sk =3D d=
pp.producto_sk)=0A  ->  Seq Scan on fact_ven_renta fvr  (cost=3D0.00..6044.=
16 rows=3D136316 width=3D228) (actual time=3D0.029..452.716 rows=3D136316 l=
oops=3D1)=0A  ->  Hash  (cost=3D403.69..403.69 rows=3D3669 width=3D676) (ac=
tual time=3D50.582..50.582 rows=3D3669 loops=3D1)=0A        ->  Seq Scan on=
 dim_producto_std_producto dpp  (cost=3D0.00..403.69 rows=3D3669 width=3D67=
6) (actual time=3D0.023..19.776 rows=3D3669 loops=3D1)=0ATotal runtime: 202=
2.293 ms=0A=0AAnd this is the plan for the new server:=0AHash Join  (cost=
=3D412.86..9524.13 rows=3D136316 width=3D905) (actual time=3D9.421..506.376=
 rows=3D136316 loops=3D1)=0A  Hash Cond: ("outer".producto_std_producto_sk =
=3D "inner".producto_sk)=0A  ->  Seq Scan on fact_ven_renta fvr  (cost=3D0.=
00..6044.16 rows=3D136316 width=3D228) (actual time=3D0.006..107.318 rows=
=3D136316 loops=3D1)=0A  ->  Hash  (cost=3D403.69..403.69 rows=3D3669 width=
=3D677) (actual time=3D9.385..9.385 rows=3D3669 loops=3D1)=0A        ->  Se=
q Scan on dim_producto_std_producto dpp  (cost=3D0.00..403.69 rows=3D3669 w=
idth=3D677) (actual time=3D0.003..3.157 rows=3D3669 loops=3D1)=0ATotal runt=
ime: 553.619 ms=0A=0A=0AI see an "outer" join in the plan for the new serve=
r. This is weird!!! There are the same databases in both servers.=0AThe old=
 one runs this query for about 37 seconds and for the new one for about 301=
 seconds.=0AWhy are plans different? May the backup recovery process have h=
ad an error in the new server when restoring?=0A=0AI appreciate some help.=
=0ARegards Agustin=0A=0A----- Mensaje original ----=0ADe: "brauagustin-susc=
@yahoo.com.ar" <brauagustin-susc@yahoo.com.ar>=0APara: pgsql-performance@po=
stgresql.org=0AEnviado: mi=E9rcoles 19 de septiembre de 2007, 14:38:13=0AAs=
unto: [PERFORM] Low CPU Usage=0A=0AHi all.=0ARecently I have installed a br=
and new server with a Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4=
.0r1 with PostgreSQL 8.2.4 (previously a 8.1.9).=0AI have other similar ser=
ver with an IDE disk, Red Hat EL 4 and PostgreSQL 8.2.3=0A=0AI have almost =
the same postgresql.conf in both servers, but in the new one (I have more w=
ork_mem than the other one) things go really slow.  I began to monitor i/o =
disk and it's really ok, I have test disk with hdparm and it's 5 times fast=
er than the IDE one.=0ARunning the same queries in both servers in the new =
one it envolves almost 4 minutes instead of 18 seconds in the old one.=0ABo=
th databases are the same, I have vacuum them and I don't know how to manag=
e this issue.=0AThe only weird thing is than in the older server running=0A=
 the query it uses 30% of CPU instead of 3 o 5 % of the new one!!!=0AWhat's=
 is happening with this server? I upgrade from 8.1.9 to 8.2.4 trying to sol=
ve this issue but I can't find a solution.=0A=0AAny ideas?=0ARegards=0AAgus=
tin=0A=0A=0A=0A=0A      =0AEl Mundial de Rugby 2007=0ALas =FAltimas noticia=
s en Yahoo! Deportes:=0A=0Ahttp://ar.sports.yahoo.com/mundialderugby=0A=0A=
=0A=0A=0A=0A      Los referentes m=E1s importantes en compra/ venta de auto=
s se juntaron:=0ADemotores y Yahoo!=0AAhora comprar o vender tu auto es m=
=E1s f=E1cil. Vist=E1 ar.autos.yahoo.com/
--0-1748347442-1190395845=:47531
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">I'm doing several tests.<br>Right now I did a VACUU=
M FULL ANALYZE in both servers.<br>In the old one vacuum runs for about 354=
 seconds and in the new one 59 seconds.<br><br>Then I have ran<br>EXPLAIN A=
NALYZE<br>SELECT *<br>FROM fact_ven_renta fvr, dim_producto_std_producto dp=
p<br>WHERE<br>&nbsp; fvr.producto_std_producto_sk =3D dpp.producto_sk<br><b=
r>I have found that the plans aren't exactly the same.<br>This is the plan =
for the old server:<br>Hash Join&nbsp; (cost=3D449.55..8879.24 rows=3D13631=
6 width=3D904) (actual time=3D50.734..1632.491 rows=3D136316 loops=3D1)<br>=
&nbsp; Hash Cond: (fvr.producto_std_producto_sk =3D dpp.producto_sk)<br>&nb=
sp; -&gt;&nbsp; Seq Scan on fact_ven_renta fvr&nbsp; (cost=3D0.00..6044.16 =
rows=3D136316
 width=3D228) (actual time=3D0.029..452.716 rows=3D136316 loops=3D1)<br>&nb=
sp; -&gt;&nbsp; Hash&nbsp; (cost=3D403.69..403.69 rows=3D3669 width=3D676) =
(actual time=3D50.582..50.582 rows=3D3669 loops=3D1)<br>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; Seq Scan on dim_producto_std_producto d=
pp&nbsp; (cost=3D0.00..403.69 rows=3D3669 width=3D676) (actual time=3D0.023=
..19.776 rows=3D3669 loops=3D1)<br>Total runtime: 2022.293 ms<br><br>And th=
is is the plan for the new server:<br>Hash Join&nbsp; (cost=3D412.86..9524.=
13 rows=3D136316 width=3D905) (actual time=3D9.421..506.376 rows=3D136316 l=
oops=3D1)<br>&nbsp; Hash Cond: ("outer".producto_std_producto_sk =3D "inner=
".producto_sk)<br>&nbsp; -&gt;&nbsp; Seq Scan on fact_ven_renta fvr&nbsp; (=
cost=3D0.00..6044.16 rows=3D136316 width=3D228) (actual time=3D0.006..107.3=
18 rows=3D136316 loops=3D1)<br>&nbsp; -&gt;&nbsp; Hash&nbsp; (cost=3D403.69=
..403.69 rows=3D3669 width=3D677) (actual time=3D9.385..9.385 rows=3D3669 l=
oops=3D1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 -&gt;&nbsp; Seq Scan on dim_producto_std_producto dpp&nbsp; (cost=3D0.00..=
403.69 rows=3D3669 width=3D677) (actual time=3D0.003..3.157 rows=3D3669 loo=
ps=3D1)<br>Total runtime: 553.619 ms<br><br><br>I see an "outer" join in th=
e plan for the new server. This is weird!!! There are the same databases in=
 both servers.<br>The old one runs this query for about 37 seconds and for =
the new one for about 301 seconds.<br>Why are plans different? May the back=
up recovery process have had an error in the new server when restoring?<br>=
<br>I appreciate some help.<br>Regards Agustin<br><br><div style=3D"font-fa=
mily: times new roman,new york,times,serif; font-size: 12pt;">----- Mensaje=
 original ----<br>De: "brauagustin-susc@yahoo.com.ar" &lt;brauagustin-susc@=
yahoo.com.ar&gt;<br>Para: pgsql-performance@postgresql.org<br>Enviado: mi=
=E9rcoles 19 de septiembre de 2007, 14:38:13<br>Asunto: [PERFORM] Low CPU U=
sage<br><br><div style=3D"font-family: times new roman,new york,times,serif=
; font-size:
 12pt;"><div>Hi all.<br>Recently I have installed a brand new server with a=
 Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL =
8.2.4 (previously a 8.1.9).<br>I have other similar server with an IDE disk=
, Red Hat EL 4 and PostgreSQL 8.2.3<br><br>I have almost the same postgresq=
l.conf in both servers, but in the new one (I have more work_mem than the o=
ther one) things go really slow.&nbsp; I began to monitor i/o disk and it's=
 really ok, I have test disk with hdparm and it's 5 times faster than the I=
DE one.<br>Running the same queries in both servers in the new one it envol=
ves almost 4 minutes instead of 18 seconds in the old one.<br>Both database=
s are the same, I have vacuum them and I don't know how to manage this issu=
e.<br>The only weird thing is than in the older server running=0A the query=
 it uses 30% of CPU instead of 3 o 5 % of the new one!!!<br>What's is happe=
ning with this server? I upgrade from 8.1.9 to 8.2.4 trying to solve this i=
ssue but I can't find a solution.<br><br>Any ideas?<br>Regards<br>Agustin<b=
r></div></div><br>=0A      <hr size=3D"1"><br><font face=3D"Verdana" size=
=3D"-2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deport=
es:<br><span>=0A<a target=3D"_blank" href=3D"http://ar.sports.yahoo.com/mun=
dialderugby">http://ar.sports.yahoo.com/mundialderugby</a></span></font></d=
iv><br></div></div><br>=0A=0A=0A=0A      <hr size=3D1><br><font face=3D"Ver=
dana" size=3D"-2">Los referentes m=E1s importantes en compra/venta de autos=
 se juntaron:<br>Demotores y Yahoo!.=0AAhora comprar o vender tu auto es m=
=E1s f=E1cil. <br> Visit=E1 http://ar.autos.yahoo.com/</font></body></html>
--0-1748347442-1190395845=:47531--



From brauagustin-susc@yahoo.com.ar Fri Sep  21 17:52:03 2007
Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 8B5879FB219
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:52:03 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 74889-06-5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:51:59 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30003.mail.mud.yahoo.com (web30003.mail.mud.yahoo.com
	[209.191.69.20]) by postgresql.org (Postfix) with SMTP id C35799FB378
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 14:51:58 -0300 (ADT)
Received: (qmail 78318 invoked by uid 60001); 21 Sep 2007 17:51:57 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=tjZeszWTFZg3poZl1sVXRucUUr0db8DZvGF0mk07AzIGbnXB2VpE9obyf4bI4eag5jiIhs+qzQOdOMayANDYxIngy3d6e2X8pTrqmr7dOXLCNaLGG8S+z5TSqIj4WxGr3tIazoCCwkfpjRBHkcwtHVg5OJUL/yUNvNS0gItTTEU=;
X-YMail-OSG: 
 UGc0xQ8VM1lBtTnYHzEbQ8hTRCDTnT_f3scTqRbeMC1N5v8fF9Wh1yJjCLDtszfyb1r1P4t0heUfcimMqOf4K5kfhgj363CKr1LJ8puzqpd9GgSYCU373N1W5T6owg--
Received: from [68.142.201.144] by web30003.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 10:51:57 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 10:51:57 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: brauagustin-susc@yahoo.com.ar, pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1600521081-1190397117=:77287"
Message-ID: <540890.77287.qm@web30003.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/375
X-Sequence-Number: 26920

--0-1600521081-1190397117=:77287
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I forgot to tell this plan was with Postgres 8.1.9 in the new server with p=
ostgres 8.2.4 in the new server the plan is the same as with te old one (th=
e little difference in rows retrieved is that the database is yesterday sna=
pshot).=0AThis is the plan for the new server with postgres 8.2.4:=0AHash J=
oin  (cost=3D449.55..8846.67 rows=3D135786 width=3D904) (actual time=3D10.8=
23..467.746 rows=3D135786 loops=3D1)=0A  Hash Cond: (fvr.producto_std_produ=
cto_sk =3D dpp.producto_sk)=0A  ->  Seq Scan on fact_ven_renta fvr  (cost=
=3D0.00..6020.86 rows=3D135786 width=3D228) (actual time=3D0.007..81.268 ro=
ws=3D135786 loops=3D1)=0A  ->  Hash  (cost=3D403.69..403.69 rows=3D3669 wid=
th=3D676) (actual time=3D10.733..10.733 rows=3D3669 loops=3D1)=0A        ->=
  Seq Scan on dim_producto_std_producto dpp  (cost=3D0.00..403.69 rows=3D36=
69 width=3D676) (actual time=3D0.004..2.995 rows=3D3669 loops=3D1)=0ATotal =
runtime: 513.747 ms=0A=0AThis query is running for about 200 seconds, doing=
 dstat I don't see anything weird (regards to low cpu usage 2% or 3%) and n=
ormal i/o. In the old server I have 30% of cpu usage an high i/o and run fa=
ster!!!=0AThis is really weird.=0A=0A=0A----- Mensaje original ----=0ADe: "=
brauagustin-susc@yahoo.com.ar" <brauagustin-susc@yahoo.com.ar>=0APara: pgsq=
l-performance@postgresql.org=0AEnviado: viernes 21 de septiembre de 2007, 1=
4:30:45=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AI'm doing several tests.=
=0ARight now I did a VACUUM FULL ANALYZE in both servers.=0AIn the old one =
vacuum runs for about 354 seconds and in the new one 59 seconds.=0A=0AThen =
I have ran=0AEXPLAIN ANALYZE=0ASELECT *=0AFROM fact_ven_renta fvr, dim_prod=
ucto_std_producto dpp=0AWHERE=0A  fvr.producto_std_producto_sk =3D dpp.prod=
ucto_sk=0A=0AI have found that the plans aren't exactly the same.=0AThis is=
 the plan for the old server:=0AHash Join  (cost=3D449.55..8879.24 rows=3D1=
36316 width=3D904) (actual time=3D50.734..1632.491 rows=3D136316 loops=3D1)=
=0A  Hash Cond: (fvr.producto_std_producto_sk =3D dpp.producto_sk)=0A  ->  =
Seq Scan on fact_ven_renta fvr  (cost=3D0.00..6044.16 rows=3D136316=0A widt=
h=3D228) (actual time=3D0.029..452.716 rows=3D136316 loops=3D1)=0A  ->  Has=
h  (cost=3D403.69..403.69 rows=3D3669 width=3D676) (actual time=3D50.582..5=
0.582 rows=3D3669 loops=3D1)=0A        ->  Seq Scan on dim_producto_std_pro=
ducto dpp  (cost=3D0.00..403.69 rows=3D3669 width=3D676) (actual time=3D0.0=
23..19.776 rows=3D3669 loops=3D1)=0ATotal runtime: 2022.293 ms=0A=0AAnd thi=
s is the plan for the new server:=0AHash Join  (cost=3D412.86..9524.13 rows=
=3D136316 width=3D905) (actual time=3D9.421..506.376 rows=3D136316 loops=3D=
1)=0A  Hash Cond: ("outer".producto_std_producto_sk =3D "inner".producto_sk=
)=0A  ->  Seq Scan on fact_ven_renta fvr  (cost=3D0.00..6044.16 rows=3D1363=
16 width=3D228) (actual time=3D0.006..107.318 rows=3D136316 loops=3D1)=0A  =
->  Hash  (cost=3D403.69..403.69 rows=3D3669 width=3D677) (actual time=3D9.=
385..9.385 rows=3D3669 loops=3D1)=0A       =0A ->  Seq Scan on dim_producto=
_std_producto dpp  (cost=3D0.00..403.69 rows=3D3669 width=3D677) (actual ti=
me=3D0.003..3.157 rows=3D3669 loops=3D1)=0ATotal runtime: 553.619 ms=0A=0A=
=0AI see an "outer" join in the plan for the new server. This is weird!!! T=
here are the same databases in both servers.=0AThe old one runs this query =
for about 37 seconds and for the new one for about 301 seconds.=0AWhy are p=
lans different? May the backup recovery process have had an error in the ne=
w server when restoring?=0A=0AI appreciate some help.=0ARegards Agustin=0A=
=0A----- Mensaje original ----=0ADe: "brauagustin-susc@yahoo.com.ar" <braua=
gustin-susc@yahoo.com.ar>=0APara: pgsql-performance@postgresql.org=0AEnviad=
o: mi=E9rcoles 19 de septiembre de 2007, 14:38:13=0AAsunto: [PERFORM] Low C=
PU Usage=0A=0AHi all.=0ARecently I have installed a brand new server with a=
 Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL =
8.2.4 (previously a 8.1.9).=0AI have other similar server with an IDE disk,=
 Red Hat EL 4 and PostgreSQL 8.2.3=0A=0AI have almost the same postgresql.c=
onf in both servers, but in the new one (I have more work_mem than the othe=
r one) things go really slow.  I began to monitor i/o disk and it's really =
ok, I have test disk with hdparm and it's 5 times faster than the IDE one.=
=0ARunning the same queries in both servers in the new one it envolves almo=
st 4 minutes instead of 18 seconds in the old one.=0ABoth databases are the=
 same, I have vacuum them and I don't know how to manage this issue.=0AThe =
only weird thing is than in the older server running=0A the query it uses 3=
0% of CPU instead of 3 o 5 % of the new one!!!=0AWhat's is happening with t=
his server? I upgrade from 8.1.9 to 8.2.4 trying to solve this issue but I =
can't find a solution.=0A=0AAny ideas?=0ARegards=0AAgustin=0A=0A=0A=0A=0A  =
    =0AEl Mundial de Rugby 2007=0ALas =FAltimas noticias en Yahoo! Deportes=
:=0A=0Ahttp://ar.sports.yahoo.com/mundialderugby=0A=0A=0A=0A=0A=0A=0A=0A=0A=
      =0ALos referentes m=E1s importantes en compra/venta de autos se junta=
ron:=0ADemotores y Yahoo!.=0AAhora comprar o vender tu auto es m=E1s f=E1ci=
l. =0A Visit=E1 http://ar.autos.yahoo.com/=0A=0A=0A=0A=0A=0A      Los refer=
entes m=E1s importantes en compra/ venta de autos se juntaron:=0ADemotores =
y Yahoo!=0AAhora comprar o vender tu auto es m=E1s f=E1cil. Vist=E1 ar.auto=
s.yahoo.com/
--0-1600521081-1190397117=:77287
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">I forgot to tell this plan was with Postgres 8.1.9 =
in the new server with postgres 8.2.4 in the new server the plan is the sam=
e as with te old one (the little difference in rows retrieved is that the d=
atabase is yesterday snapshot).<br>This is the plan for the new server with=
 postgres 8.2.4:<br>Hash Join&nbsp; (cost=3D449.55..8846.67 rows=3D135786 w=
idth=3D904) (actual time=3D10.823..467.746 rows=3D135786 loops=3D1)<br>&nbs=
p; Hash Cond: (fvr.producto_std_producto_sk =3D dpp.producto_sk)<br>&nbsp; =
-&gt;&nbsp; Seq Scan on fact_ven_renta fvr&nbsp; (cost=3D0.00..6020.86 rows=
=3D135786 width=3D228) (actual time=3D0.007..81.268 rows=3D135786 loops=3D1=
)<br>&nbsp; -&gt;&nbsp; Hash&nbsp; (cost=3D403.69..403.69 rows=3D3669 width=
=3D676) (actual
 time=3D10.733..10.733 rows=3D3669 loops=3D1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; -&gt;&nbsp; Seq Scan on dim_producto_std_producto dpp&nbsp=
; (cost=3D0.00..403.69 rows=3D3669 width=3D676) (actual time=3D0.004..2.995=
 rows=3D3669 loops=3D1)<br>Total runtime: 513.747 ms<br><br>This query is r=
unning for about 200 seconds, doing dstat I don't see anything weird (regar=
ds to low cpu usage 2% or 3%) and normal i/o. In the old server I have 30% =
of cpu usage an high i/o and run faster!!!<br>This is really weird.<br><br>=
<br><div style=3D"font-family: times new roman,new york,times,serif; font-s=
ize: 12pt;">----- Mensaje original ----<br>De: "brauagustin-susc@yahoo.com.=
ar" &lt;brauagustin-susc@yahoo.com.ar&gt;<br>Para: pgsql-performance@postgr=
esql.org<br>Enviado: viernes 21 de septiembre de 2007, 14:30:45<br>Asunto: =
Re: [PERFORM] Low CPU Usage<br><br><div style=3D"font-family: times new rom=
an,new york,times,serif; font-size: 12pt;"><div style=3D"font-family: times=
 new roman,new
 york,times,serif; font-size: 12pt;">I'm doing several tests.<br>Right now =
I did a VACUUM FULL ANALYZE in both servers.<br>In the old one vacuum runs =
for about 354 seconds and in the new one 59 seconds.<br><br>Then I have ran=
<br>EXPLAIN ANALYZE<br>SELECT *<br>FROM fact_ven_renta fvr, dim_producto_st=
d_producto dpp<br>WHERE<br>&nbsp; fvr.producto_std_producto_sk =3D dpp.prod=
ucto_sk<br><br>I have found that the plans aren't exactly the same.<br>This=
 is the plan for the old server:<br>Hash Join&nbsp; (cost=3D449.55..8879.24=
 rows=3D136316 width=3D904) (actual time=3D50.734..1632.491 rows=3D136316 l=
oops=3D1)<br>&nbsp; Hash Cond: (fvr.producto_std_producto_sk =3D dpp.produc=
to_sk)<br>&nbsp; -&gt;&nbsp; Seq Scan on fact_ven_renta fvr&nbsp; (cost=3D0=
.00..6044.16 rows=3D136316=0A width=3D228) (actual time=3D0.029..452.716 ro=
ws=3D136316 loops=3D1)<br>&nbsp; -&gt;&nbsp; Hash&nbsp; (cost=3D403.69..403=
.69 rows=3D3669 width=3D676) (actual time=3D50.582..50.582 rows=3D3669 loop=
s=3D1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; Seq Scan o=
n dim_producto_std_producto dpp&nbsp; (cost=3D0.00..403.69 rows=3D3669 widt=
h=3D676) (actual time=3D0.023..19.776 rows=3D3669 loops=3D1)<br>Total runti=
me: 2022.293 ms<br><br>And this is the plan for the new server:<br>Hash Joi=
n&nbsp; (cost=3D412.86..9524.13 rows=3D136316 width=3D905) (actual time=3D9=
.421..506.376 rows=3D136316 loops=3D1)<br>&nbsp; Hash Cond: ("outer".produc=
to_std_producto_sk =3D "inner".producto_sk)<br>&nbsp; -&gt;&nbsp; Seq Scan =
on fact_ven_renta fvr&nbsp; (cost=3D0.00..6044.16 rows=3D136316 width=3D228=
) (actual time=3D0.006..107.318 rows=3D136316 loops=3D1)<br>&nbsp; -&gt;&nb=
sp; Hash&nbsp; (cost=3D403.69..403.69 rows=3D3669 width=3D677) (actual time=
=3D9.385..9.385 rows=3D3669 loops=3D1)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=0A -&gt;&nbsp; Seq Scan on dim_producto_std_producto dpp&nbsp; (c=
ost=3D0.00..403.69 rows=3D3669 width=3D677) (actual time=3D0.003..3.157 row=
s=3D3669 loops=3D1)<br>Total runtime: 553.619 ms<br><br><br>I see an "outer=
" join in the plan for the new server. This is weird!!! There are the same =
databases in both servers.<br>The old one runs this query for about 37 seco=
nds and for the new one for about 301 seconds.<br>Why are plans different? =
May the backup recovery process have had an error in the new server when re=
storing?<br><br>I appreciate some help.<br>Regards Agustin<br><br><div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;">-=
---- Mensaje original ----<br>De: "brauagustin-susc@yahoo.com.ar" &lt;braua=
gustin-susc@yahoo.com.ar&gt;<br>Para: pgsql-performance@postgresql.org<br>E=
nviado: mi=E9rcoles 19 de septiembre de 2007, 14:38:13<br>Asunto: [PERFORM]=
 Low CPU Usage<br><br><div style=3D"font-family: times new roman,new york,t=
imes,serif; font-size:
 12pt;"><div>Hi all.<br>Recently I have installed a brand new server with a=
 Pentium IV 3.2 GHz, SATA Disk, 2GB of Ram in Debian 4.0r1 with PostgreSQL =
8.2.4 (previously a 8.1.9).<br>I have other similar server with an IDE disk=
, Red Hat EL 4 and PostgreSQL 8.2.3<br><br>I have almost the same postgresq=
l.conf in both servers, but in the new one (I have more work_mem than the o=
ther one) things go really slow.&nbsp; I began to monitor i/o disk and it's=
 really ok, I have test disk with hdparm and it's 5 times faster than the I=
DE one.<br>Running the same queries in both servers in the new one it envol=
ves almost 4 minutes instead of 18 seconds in the old one.<br>Both database=
s are the same, I have vacuum them and I don't know how to manage this issu=
e.<br>The only weird thing is than in the older server running=0A the query=
 it uses 30% of CPU instead of 3 o 5 % of the new one!!!<br>What's is happe=
ning with this server? I upgrade from 8.1.9 to 8.2.4 trying to solve this i=
ssue but I can't find a solution.<br><br>Any ideas?<br>Regards<br>Agustin<b=
r></div></div><br>=0A      <hr size=3D"1"><br><font face=3D"Verdana" size=
=3D"-2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deport=
es:<br><span>=0A<a rel=3D"nofollow" target=3D"_blank" href=3D"http://ar.spo=
rts.yahoo.com/mundialderugby">http://ar.sports.yahoo.com/mundialderugby</a>=
</span></font></div><br></div></div><br>=0A=0A=0A=0A      <hr size=3D"1"><b=
r><font face=3D"Verdana" size=3D"-2">Los referentes m=E1s importantes en co=
mpra/venta de autos se juntaron:<br>Demotores y Yahoo!.=0AAhora comprar o v=
ender tu auto es m=E1s f=E1cil. <br><span> Visit=E1 <a target=3D"_blank" hr=
ef=3D"http://ar.autos.yahoo.com/">http://ar.autos.yahoo.com/</a></span></fo=
nt></div><br></div></div><br>=0A      <hr size=3D1><br><font face=3D"Verdan=
a" size=3D"-2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo!=
 Deportes:<br>=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></h=
tml>
--0-1600521081-1190397117=:77287--



From Kevin.Grittner@wicourts.gov Fri Sep  21 17:52:04 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id AC4409FB219
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:52:04 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 69999-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 14:51:59 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by postgresql.org (Postfix) with ESMTP id 0493C9FB232
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 14:52:00 -0300 (ADT)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Fri, 21 Sep 2007 12:52:00 -0500
Message-Id: <46F3BE6C.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.2 
Date: Fri, 21 Sep 2007 12:51:57 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: <pgsql-performance@postgresql.org>,<brauagustin-susc@yahoo.com.ar>
Subject: Re: Low CPU Usage
References: <121711.47531.qm@web30006.mail.mud.yahoo.com>
In-Reply-To: <121711.47531.qm@web30006.mail.mud.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/376
X-Sequence-Number: 26921

>>> On Fri, Sep 21, 2007 at 12:30 PM, in message
<121711.47531.qm@web30006.mail.mud.yahoo.com>, <brauagustin-susc@yahoo.com.=
ar>
wrote:=20
=20
> This is the plan for the old server:
> Hash Join  (cost=3D449.55..8879.24 rows=3D136316 width=3D904) (actual=20
> time=3D50.734..1632.491 rows=3D136316 loops=3D1)
. . .
> Total runtime: 2022.293 ms
=20
> And this is the plan for the new server:
> Hash Join  (cost=3D412.86..9524.13 rows=3D136316 width=3D905) (actual=20
> time=3D9.421..506.376 rows=3D136316 loops=3D1)
. . .
> Total runtime: 553.619 ms
=20
> I see an "outer" join in the plan for the new server. This is weird!!! =
There=20
> are the same databases in both servers.
=20
That's just a matter of labeling the tables with role rather than alias.
The plans look the same to me.
=20
> The old one runs this query for about 37 seconds and for the new one =
for=20
> about 301 seconds.
=20
That's not what it looks like based on the EXPLAIN ANALYZE output.
It looks like run time dropped from two seconds to half a second.
=20
It seems as though you either have a network delay delivering the results,
or your application is slow to read them.

Exactly how are you arriving at those timings you're reporting to us?
=20
-Kevin
=20





From brauagustin-susc@yahoo.com.ar Fri Sep  21 18:20:35 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 1ADBC9F9941
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:20:35 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 10821-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:20:30 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30009.mail.mud.yahoo.com (web30009.mail.mud.yahoo.com
	[209.191.69.26]) by postgresql.org (Postfix) with SMTP id AF7A89F9919
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 15:20:31 -0300 (ADT)
Received: (qmail 2070 invoked by uid 60001); 21 Sep 2007 18:20:30 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
	b=FwOE/XC0oyJJVpvCF68Kml1I30nhIQBgHhz+S1SON6bzS4dalPSD8FnvINn05lkBsb/U21X097cdovOtQDqbNnjECLG5xwyE2dVT7T14NTvNS06GlZ0OkzxgZBUfk6P2ZNWuPPHh0QnD4KVUq5H4HiVZN5hCn2+lq2858HxAdIw=;
X-YMail-OSG: 
 xzkj5QcVM1lUJ6I_jdPJasXZJfkG7842gmqd3wTzf0ew6gbylRWipFFBLz5aEaeHpg--
Received: from [68.142.201.149] by web30009.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 11:20:30 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 11:20:30 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1311541771-1190398830=:746"
Message-ID: <582823.746.qm@web30009.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/378
X-Sequence-Number: 26923

--0-1311541771-1190398830=:746
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> That's not what it looks like based on the EXPLAIN ANALYZE output.=0A> It=
 looks like run time dropped from two seconds to half a second.=0A =0A> It =
seems as though you either have a network delay delivering the results,=0A>=
 or your application is slow to read them.=0A=0A> Exactly how are you arriv=
ing at those timings you're reporting to us?=0A =0AI have noticed this in a=
 daly process I run which involves normally 45 minutes and with the new ser=
ver takes 1:40.=0A=0ASome days ago I began to do some tests with no success=
, then I opened PgAdmin with this simply query to read 2 big tables and the=
n compare disk access.=0ASELECT *=0AFROM fact_ven_renta fvr, dim_producto_s=
td_producto dpp=0AWHERE=0A  fvr.producto_std_producto_sk =3D dpp.producto_s=
k=0A =0Afact_ven_renta has 136316 rows=0Adim_producto_std_producto has 3669=
 rows=0A=0A=0A=0AI have made all possible combinations pgadmin (running in =
the same server each query, in the old one, in the new one), without differ=
ence  and I only retrieve the first 100 records (I didn't count the network=
 time in any case).=0ABut the weird thing is running the query in the new s=
erver the are many disk access and cpu usage. And with other applications i=
n the same server are a lot of disks access.=0A=0A=0A=0A=0A=0A=0A      Segu=
=ED de cerca a la Selecci=F3n Argentina de Rugby en el Mundial de Francia 2=
007.=0Ahttp://ar.sports.yahoo.com/mundialderugby
--0-1311541771-1190398830=:746
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;"><div style=3D"font-family: times new roman,new york=
,times,serif; font-size: 12pt;"><div>&gt; That's not what it looks like bas=
ed on the EXPLAIN ANALYZE output.<br>&gt; It looks like run time dropped fr=
om two seconds to half a second.<br> <br>&gt; It seems as though you either=
 have a network delay delivering the results,<br>&gt; or your application i=
s slow to read them.<br><br>&gt; Exactly how are you arriving at those timi=
ngs you're reporting to us?<br> <br>I have noticed this in a daly process I=
 run which involves normally 45 minutes and with the new server takes 1:40.=
<br><br>Some days ago I began to do some tests with no success, then I open=
ed PgAdmin with this simply query to read 2 big tables and then compare dis=
k
 access.<br>SELECT *<br>FROM fact_ven_renta fvr, dim_producto_std_producto =
dpp<br>WHERE<br>&nbsp; fvr.producto_std_producto_sk =3D dpp.producto_sk<br>=
 <br>fact_ven_renta has 136316 rows<br>dim_producto_std_producto has 3669 r=
ows<br></div></div><br>I have made all possible combinations pgadmin (runni=
ng in the same server each query, in the old one, in the new one), without =
difference&nbsp; and I only retrieve the first 100 records (I didn't count =
the network time in any case).<br>But the weird thing is running the query =
in the new server the are many disk access and cpu usage. And with other ap=
plications in the same server are a lot of disks access.<br><br><br></div><=
/div><br>=0A=0A=0A=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"=
-2">Los referentes m=E1s importantes en compra/venta de autos se juntaron:<=
br>Demotores y Yahoo!.=0AAhora comprar o vender tu auto es m=E1s f=E1cil. <=
br> Visit=E1 http://ar.autos.yahoo.com/</font></body></html>
--0-1311541771-1190398830=:746--



From wmoran@collaborativefusion.com Fri Sep  21 18:34:16 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id E6E989FB4DF
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:34:16 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 09553-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:34:03 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mx00.pub.collaborativefusion.com
	(mx00.pub.collaborativefusion.com [206.210.89.199])
	by postgresql.org (Postfix) with ESMTP id CB5269FB4DB
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 15:34:05 -0300 (ADT)
Received: from vanquish.pitbpa0.priv.collaborativefusion.com
	(vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61])
	(SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wingspan with esmtp; Fri, 21 Sep 2007 14:33:54 -0400
	id 00056440.46F40E92.000032A2
Date: Fri, 21 Sep 2007 14:33:54 -0400
From: Bill Moran <wmoran@collaborativefusion.com>
To: brauagustin-susc@yahoo.com.ar
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
Subject: Re: Low CPU Usage
Message-Id: <20070921143354.3d35cbff.wmoran@collaborativefusion.com>
In-Reply-To: <582823.746.qm@web30009.mail.mud.yahoo.com>
References: <582823.746.qm@web30009.mail.mud.yahoo.com>
Organization: Collaborative Fusion
X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd6.2)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/379
X-Sequence-Number: 26924

In response to brauagustin-susc@yahoo.com.ar:

> > That's not what it looks like based on the EXPLAIN ANALYZE output.
> > It looks like run time dropped from two seconds to half a second.
>  
> > It seems as though you either have a network delay delivering the results,
> > or your application is slow to read them.
> 
> > Exactly how are you arriving at those timings you're reporting to us?
>  
> I have noticed this in a daly process I run which involves normally 45 minutes and with the new server takes 1:40.
> 
> Some days ago I began to do some tests with no success, then I opened PgAdmin with this simply query to read 2 big tables and then compare disk access.
> SELECT *
> FROM fact_ven_renta fvr, dim_producto_std_producto dpp
> WHERE
>   fvr.producto_std_producto_sk = dpp.producto_sk
>  
> fact_ven_renta has 136316 rows
> dim_producto_std_producto has 3669 rows

Run the tests from psql on the same server.  As Kevin pointed out, the
_server_ is faster, but it appears as if the connection between PGadmin
and this new server is slower somehow.

Are you sure of your speed/duplex settings on the network side?  That's
the most common cause of this kind of thing in my experience.  Try doing
a raw FTP transfer between the client and server and see if you get the
speed you should.

> 
> 
> 
> I have made all possible combinations pgadmin (running in the same server each query, in the old one, in the new one), without difference  and I only retrieve the first 100 records (I didn't count the network time in any case).
> But the weird thing is running the query in the new server the are many disk access and cpu usage. And with other applications in the same server are a lot of disks access.



-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023



From brauagustin-susc@yahoo.com.ar Fri Sep  21 19:01:43 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id A12229FB4D1
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:01:43 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 14762-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:01:33 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30014.mail.mud.yahoo.com (web30014.mail.mud.yahoo.com
	[209.191.69.31]) by postgresql.org (Postfix) with SMTP id E76A59FB223
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 16:01:35 -0300 (ADT)
Received: (qmail 2675 invoked by uid 60001); 21 Sep 2007 19:01:34 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=PlcrwlpXjFouSXGZmliEwoT1UEDlEdv1a5TFy7GWFk0TKPm20tGMCx75xaQipaVX1GkO+tu2xXRLk8TkOz05Hq1GnnNsnZkMFFUxKuCFYXBiCPerVbT8QeYD55hFTo7uB+A7WNHy4UryLJxjjwbUKbFbeRzQO97nECoRp/iGrHk=;
X-YMail-OSG: 
 eK.5QJ0VM1kO8ZO1v3Ik4hwTL6CCTXEIU7EdAwFS0eoVbmOwapGDXuv7_LlzMVD40zbWV30OL.P2pQOsX_TXS05CYwp99e_waPhB2fzRiKtY4hMDAib79rnobmWJIQ--
Received: from [209.191.119.123] by web30014.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 12:01:34 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 12:01:34 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Bill Moran <wmoran@collaborativefusion.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1069428067-1190401294=:2406"
Message-ID: <863435.2406.qm@web30014.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/381
X-Sequence-Number: 26926

--0-1069428067-1190401294=:2406
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>> > That's not what it looks like based on the EXPLAIN ANALYZE output.=0A>=
> > It looks like run time dropped from two seconds to half a second.=0A>> =
 =0A>> > It seems as though you either have a network delay delivering the =
results,=0A>> > or your application is slow to read them.=0A>> =0A>> > Exac=
tly how are you arriving at those timings you're reporting to us?=0A>>  =0A=
>> I have noticed this in a daly process I run which involves normally 45 m=
inutes and with the new server takes 1:40.=0A>> =0A>> Some days ago I began=
 to do some tests with no success, then I opened PgAdmin with this simply q=
uery to read 2 big tables and then compare disk access.=0A>> SELECT *=0A>> =
FROM fact_ven_renta fvr, dim_producto_std_producto dpp=0A>> WHERE=0A>>   fv=
r.producto_std_producto_sk =3D dpp.producto_sk=0A>>  =0A>> fact_ven_renta h=
as 136316 rows=0A>> dim_producto_std_producto has 3669 rows=0A=0A>Run the t=
ests from psql on the same server.  As Kevin pointed out, the _server_ is f=
aster, but it appears as if the connection between PGadmin and this new ser=
ver is slower somehow.=0A=0AIt runs quickly!!! But I don't know how to comp=
are because looks like it retrieve fields by demand, when I put ctrl+end (g=
o to the last record) it use a lot of CPU and disk, run quickly anyway.=0AC=
orrect me if am I wrong but, executing PgAdmin in the same server there are=
n't networks delays!=0AAnd when the server is processing the query there is=
n't network traffic because is processing the result.=0A=0A> Are you sure o=
f your speed/duplex settings on the network side?  That's=0A> the most comm=
on cause of this kind of thing in my experience.  Try doing=0A> a raw FTP t=
ransfer between the client and server and see if you get the=0A> speed you =
should.=0AThis isn't a dedicated database server, client application and se=
rver are running in the same machine!!!=0AI have stop the client applicatio=
n too with same results.=0A=0AAnyway I will do some network test to find a =
solution.=0A=0A=0A=0A=0A=0A=0A=0A=0A      Segu=ED de cerca a la Selecci=F3n=
 Argentina de Rugby en el Mundial de Francia 2007.=0Ahttp://ar.sports.yahoo=
.com/mundialderugby
--0-1069428067-1190401294=:2406
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;"><div style=3D"font-family: times new roman,new york=
,times,serif; font-size: 12pt;"><div>&gt;&gt; &gt; That's not what it looks=
 like based on the EXPLAIN ANALYZE output.<br>&gt;&gt; &gt; It looks like r=
un time dropped from two seconds to half a second.<br>&gt;&gt;&nbsp;&nbsp;<=
br>&gt;&gt; &gt; It seems as though you either have a network delay deliver=
ing the results,<br>&gt;&gt; &gt; or your application is slow to read them.=
<br>&gt;&gt; <br>&gt;&gt; &gt; Exactly how are you arriving at those timing=
s you're reporting to us?<br>&gt;&gt;&nbsp;&nbsp;<br>&gt;&gt; I have notice=
d this in a daly process I run which involves normally 45 minutes and with =
the new server takes 1:40.<br>&gt;&gt; <br>&gt;&gt; Some days ago I began t=
o
 do some tests with no success, then I opened PgAdmin with this simply quer=
y to read 2 big tables and then compare disk access.<br>&gt;&gt; SELECT *<b=
r>&gt;&gt; FROM fact_ven_renta fvr, dim_producto_std_producto dpp<br>&gt;&g=
t; WHERE<br>&gt;&gt;&nbsp;&nbsp; fvr.producto_std_producto_sk =3D dpp.produ=
cto_sk<br>&gt;&gt;&nbsp;&nbsp;<br>&gt;&gt; fact_ven_renta has 136316 rows<b=
r>&gt;&gt; dim_producto_std_producto has 3669 rows<br><br>&gt;Run the tests=
 from psql on the same server.&nbsp;&nbsp;As Kevin pointed out, the _server=
_ is faster, but it appears as if the connection between PGadmin and this n=
ew server is slower somehow.<br><br>It runs quickly!!! But I don't know how=
 to compare because looks like it retrieve fields by demand, when I put ctr=
l+end (go to the last record) it use a lot of CPU and disk, run quickly any=
way.<br>Correct me if am I wrong but, executing PgAdmin in the same server =
there aren't networks delays!<br>And when the server is processing the
 query there isn't network traffic because is processing the result.<br><br=
>&gt; Are you sure of your speed/duplex settings on the network side?&nbsp;=
&nbsp;That's<br>&gt; the most common cause of this kind of thing in my expe=
rience.&nbsp;&nbsp;Try doing<br>&gt; a raw FTP transfer between the client =
and server and see if you get the<br>&gt; speed you should.<br>This isn't a=
 dedicated database server, client application and server are running in th=
e same machine!!!<br>I have stop the client application too with same resul=
ts.<br><br>Anyway I will do some network test to find a solution.<br><br></=
div></div><br></div></div><br>=0A      <hr size=3D1><br><font face=3D"Verda=
na" size=3D"-2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo=
! Deportes:<br>=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></=
html>
--0-1069428067-1190401294=:2406--



From wmoran@collaborativefusion.com Fri Sep  21 19:11:58 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 47F409FB4FB
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:11:58 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 17992-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:11:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mx00.pub.collaborativefusion.com
	(mx00.pub.collaborativefusion.com [206.210.89.199])
	by postgresql.org (Postfix) with ESMTP id C98D09F9816
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 16:11:49 -0300 (ADT)
Received: from vanquish.pitbpa0.priv.collaborativefusion.com
	(vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61])
	(SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by wingspan with esmtp; Fri, 21 Sep 2007 15:11:38 -0400
	id 0005641E.46F4176A.00003815
Date: Fri, 21 Sep 2007 15:11:38 -0400
From: Bill Moran <wmoran@collaborativefusion.com>
To: brauagustin-susc@yahoo.com.ar
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
Subject: Re: Low CPU Usage
Message-Id: <20070921151138.b2c939fb.wmoran@collaborativefusion.com>
In-Reply-To: <863435.2406.qm@web30014.mail.mud.yahoo.com>
References: <863435.2406.qm@web30014.mail.mud.yahoo.com>
Organization: Collaborative Fusion
X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.14; i386-portbld-freebsd6.2)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/382
X-Sequence-Number: 26927

In response to brauagustin-susc@yahoo.com.ar:

> >> > That's not what it looks like based on the EXPLAIN ANALYZE output.
> >> > It looks like run time dropped from two seconds to half a second.
> >>  
> >> > It seems as though you either have a network delay delivering the results,
> >> > or your application is slow to read them.
> >> 
> >> > Exactly how are you arriving at those timings you're reporting to us?
> >>  
> >> I have noticed this in a daly process I run which involves normally 45 minutes and with the new server takes 1:40.
> >> 
> >> Some days ago I began to do some tests with no success, then I opened PgAdmin with this simply query to read 2 big tables and then compare disk access.
> >> SELECT *
> >> FROM fact_ven_renta fvr, dim_producto_std_producto dpp
> >> WHERE
> >>   fvr.producto_std_producto_sk = dpp.producto_sk
> >>  
> >> fact_ven_renta has 136316 rows
> >> dim_producto_std_producto has 3669 rows
> 
> >Run the tests from psql on the same server.  As Kevin pointed out, the _server_ is faster, but it appears as if the connection between PGadmin and this new server is slower somehow.
> 
> It runs quickly!!! But I don't know how to compare because looks like it retrieve fields by demand, when I put ctrl+end (go to the last record) it use a lot of CPU and disk, run quickly anyway.

That's pretty odd.  If you use \timing in psql, you can get execution
time for each query, if it helps you track things down.

> Correct me if am I wrong but, executing PgAdmin in the same server there aren't networks delays!

Not network, no.  But the results of your explains seem to show that the
query is executing much faster on the new system than the old, so the
problem still becomes, "what is happening after the query completes that
is so slow?"  It's just that networking is ruled out.


-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023



From brauagustin-susc@yahoo.com.ar Fri Sep  21 19:34:00 2007
Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id 59F579FB521
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:34:00 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 08244-05 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 16:33:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30004.mail.mud.yahoo.com (web30004.mail.mud.yahoo.com
	[209.191.69.21]) by postgresql.org (Postfix) with SMTP id 77FF29FB51E
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 16:33:47 -0300 (ADT)
Received: (qmail 8531 invoked by uid 60001); 21 Sep 2007 19:33:46 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=lydXiZW5ZvlSRY4ICMHe+G22pbf/VugqOFpHgxNzWBSPE5etOBrNg5uQI6oH+OTejg+mT+A5AQKtd5iwnT5WnDB/1E/w+PsMAlfLcyEwyn34RoTNE6vqyOiYH5BZh7XEeafNOwsOt6Z0at4BtQZ9xSE7jYoQDyDuksNJ12eVv/8=;
X-YMail-OSG: 
 A9A68zIVM1n9Av4AHxv1tnP.RwG7zdQUV6ODRYJAUc0qbZF3mZUINmuBo6QDTHw485GZJniD.lt5o8q9oeVHCJEqCfvhrO44Ou4w3Z5F_hsqUyDP9Lg-
Received: from [209.191.118.120] by web30004.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 12:33:46 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 12:33:46 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Bill Moran <wmoran@collaborativefusion.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-861371963-1190403226=:8256"
Message-ID: <322942.8256.qm@web30004.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/385
X-Sequence-Number: 26930

--0-861371963-1190403226=:8256
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> > >> > That's not what it looks like based on the EXPLAIN ANALYZE output.=
=0A> > >> > It looks like run time dropped from two seconds to half a secon=
d.=0A> > >>  =0A> > >> > It seems as though you either have a network delay=
 delivering the results,=0A> > >> > or your application is slow to read the=
m.=0A> > >> =0A> > >> > Exactly how are you arriving at those timings you'r=
e reporting to us?=0A> > >>  =0A> > >> I have noticed this in a daly proces=
s I run which involves normally 45 minutes and with the new server takes 1:=
40.=0A> > >> =0A> > >> Some days ago I began to do some tests with no succe=
ss, then I opened PgAdmin with this simply query to read 2 big tables and t=
hen compare disk access.=0A> > >> SELECT *=0A> > >> FROM fact_ven_renta fvr=
, dim_producto_std_producto dpp=0A> > >> WHERE=0A> > >>   fvr.producto_std_=
producto_sk =3D dpp.producto_sk=0A> > >>  =0A> > >> fact_ven_renta has 1363=
16 rows=0A> > >> dim_producto_std_producto has 3669 rows=0A >> =0A> > >Run =
the tests from psql on the same server.  As Kevin pointed out, the _server_=
 is faster, but it appears as if the connection between PGadmin and this ne=
w server is slower somehow.=0A> > =0A> > It runs quickly!!! But I don't kno=
w how to compare because looks like it retrieve fields by demand, when I pu=
t ctrl+end (go to the last record) it use a lot of CPU and disk, run quickl=
y anyway.=0A=0A> That's pretty odd.  If you use \timing in psql, you can ge=
t execution=0A> time for each query, if it helps you track things down.=0A=
=0AYes, in the new server running with \timing it consumes 5.6 seconds and =
in the old server it consumes 25 seconds.=0A=0A> > Correct me if am I wrong=
 but, executing PgAdmin in the same server there aren't networks delays!=0A=
=0A> Not network, no.  But the results of your explains seem to show that t=
he=0A> query is executing much faster on the new system than the old, so th=
e=0A> problem still becomes, "what is happening after the query completes t=
hat=0A> is so slow?"  It's just that networking is ruled out.=0A=0AIs conne=
cted to full 100Mb, it transfers many things quick to clients. Is running A=
pache adn JBoss, transfer rate is good, I did scp to copy many archives and=
 is as quick as the old server.=0A=0AI have no idea how to continue researc=
hing this problem. Now I'm going to do some networks tests.=0A=0A=0A-- =0AB=
ill Moran=0ACollaborative Fusion Inc.=0Ahttp://people.collaborativefusion.c=
om/~wmoran/=0A=0Awmoran@collaborativefusion.com=0APhone: 412-422-3463x4023=
=0A=0A=0A=0A=0A=0A=0A=0A      Las =FAltimas noticias sobre el Mundial de Ru=
gby 2007 est=E1n en Yahoo! Deportes. =A1Conocelas!=0Ahttp://ar.sports.yahoo=
.com/mundialderugby
--0-861371963-1190403226=:8256
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;"><div style=3D"font-family: times new roman,new york=
,times,serif; font-size: 12pt;"><div>&gt; &gt; &gt;&gt; &gt; That's not wha=
t it looks like based on the EXPLAIN ANALYZE output.<br>&gt; &gt; &gt;&gt; =
&gt; It looks like run time dropped from two seconds to half a second.<br>&=
gt; &gt; &gt;&gt;&nbsp;&nbsp;<br>&gt; &gt; &gt;&gt; &gt; It seems as though=
 you either have a network delay delivering the results,<br>&gt; &gt; &gt;&=
gt; &gt; or your application is slow to read them.<br>&gt; &gt; &gt;&gt; <b=
r>&gt; &gt; &gt;&gt; &gt; Exactly how are you arriving at those timings you=
're reporting to us?<br>&gt; &gt; &gt;&gt;&nbsp;&nbsp;<br>&gt; &gt; &gt;&gt=
; I have noticed this in a daly process I run which involves normally 45
 minutes and with the new server takes 1:40.<br>&gt; &gt; &gt;&gt; <br>&gt;=
 &gt; &gt;&gt; Some days ago I began to do some tests with no success, then=
 I opened PgAdmin with this simply query to read 2 big tables and then comp=
are disk access.<br>&gt; &gt; &gt;&gt; SELECT *<br>&gt; &gt; &gt;&gt; FROM =
fact_ven_renta fvr, dim_producto_std_producto dpp<br>&gt; &gt; &gt;&gt; WHE=
RE<br>&gt; &gt; &gt;&gt;&nbsp;&nbsp; fvr.producto_std_producto_sk =3D dpp.p=
roducto_sk<br>&gt; &gt; &gt;&gt;&nbsp;&nbsp;<br>&gt; &gt; &gt;&gt; fact_ven=
_renta has 136316 rows<br>&gt; &gt; &gt;&gt; dim_producto_std_producto has =
3669 rows<br>&nbsp;&gt;&gt; <br>&gt; &gt; &gt;Run the tests from psql on th=
e same server.&nbsp;&nbsp;As Kevin pointed out, the _server_ is faster, but=
 it appears as if the connection between PGadmin and this new server is slo=
wer somehow.<br>&gt; &gt; <br>&gt; &gt; It runs quickly!!! But I don't know=
 how to compare because looks like it retrieve fields by demand, when
 I put ctrl+end (go to the last record) it use a lot of CPU and disk, run q=
uickly anyway.<br><br>&gt; That's pretty odd.&nbsp;&nbsp;If you use \timing=
 in psql, you can get execution<br>&gt; time for each query, if it helps yo=
u track things down.<br><br>Yes, in the new server running with \timing it =
consumes 5.6 seconds and in the old server it consumes 25 seconds.<br><br>&=
gt; &gt; Correct me if am I wrong but, executing PgAdmin in the same server=
 there aren't networks delays!<br><br>&gt; Not network, no.&nbsp;&nbsp;But =
the results of your explains seem to show that the<br>&gt; query is executi=
ng much faster on the new system than the old, so the<br>&gt; problem still=
 becomes, "what is happening after the query completes that<br>&gt; is so s=
low?"&nbsp;&nbsp;It's just that networking is ruled out.<br><br>Is connecte=
d to full 100Mb, it transfers many things quick to clients. Is running Apac=
he adn JBoss, transfer rate is good, I did scp to copy many archives
 and is as quick as the old server.<br><br>I have no idea how to continue r=
esearching this problem. Now I'm going to do some networks tests.<br><br><b=
r>-- <br>Bill Moran<br>Collaborative Fusion Inc.<br><a target=3D"_blank" hr=
ef=3D"http://people.collaborativefusion.com/%7Ewmoran/">http://people.colla=
borativefusion.com/~wmoran/</a><br><br>wmoran@collaborativefusion.com<br>Ph=
one: 412-422-3463x4023<br></div></div><br></div></div><br>=0A      <hr size=
=3D1><br><font face=3D"Verdana" size=3D"-2">Segu=ED de cerca a la Selecci=
=F3n Argentina de Rugby<br>en el Mundial de Francia 2007.<br>=0Ahttp://ar.s=
ports.yahoo.com/mundialderugby</font></body></html>
--0-861371963-1190403226=:8256--



From luiz@planit.com.br Fri Sep  21 20:41:05 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 8BB099F9CFB
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:41:05 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 53797-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:41:00 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from andromeda1.neonex.com.br (dns3.neonex.com.br [201.28.22.10])
	by postgresql.org (Postfix) with ESMTP id 56BAE9F9C91
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 17:41:02 -0300 (ADT)
Received: from [200.206.25.4] (helo=[127.0.0.1])
	by andromeda1.neonex.com.br with esmtpa (Exim 4.63)
	(envelope-from <luiz@planit.com.br>)
	id 1IYpJ2-0001Qt-Vn; Fri, 21 Sep 2007 17:40:57 -0300
Message-ID: <46F42C54.7070901@planit.com.br>
Date: Fri, 21 Sep 2007 17:40:52 -0300
From: "Luiz K. Matsumura" <luiz@planit.com.br>
Organization: Plan IT Tecnologia =?ISO-8859-1?Q?Inform=E1tica_Ltda=2E?=
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: brauagustin-susc@yahoo.com.ar
CC: pgsql-performance@postgresql.org
References: <322942.8256.qm@web30004.mail.mud.yahoo.com>
In-Reply-To: <322942.8256.qm@web30004.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 000775-4, 09/20/2007), Outbound message
X-Antivirus-Status: Clean
X-SA-Exim-Connect-IP: 200.206.25.4
X-SA-Exim-Rcpt-To: brauagustin-susc@yahoo.com.ar,
	pgsql-performance@postgresql.org
Subject: Re: Low CPU Usage
X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/388
X-Sequence-Number: 26933



brauagustin-susc@yahoo.com.ar wrote:
>
> > That's pretty odd.  If you use \timing in psql, you can get execution
> > time for each query, if it helps you track things down.
>
> Yes, in the new server running with \timing it consumes 5.6 seconds 
> and in the old server it consumes 25 seconds.
>
> > > Correct me if am I wrong but, executing PgAdmin in the same server 
> there aren't networks delays!
>
> > Not network, no.  But the results of your explains seem to show that the
> > query is executing much faster on the new system than the old, so the
> > problem still becomes, "what is happening after the query completes that
> > is so slow?"  It's just that networking is ruled out.
>
> Is connected to full 100Mb, it transfers many things quick to clients. 
> Is running Apache adn JBoss, transfer rate is good, I did scp to copy 
> many archives and is as quick as the old server.
>
> I have no idea how to continue researching this problem. Now I'm going 
> to do some networks tests.
>
>
See if this can give some help to you:
I was experienced some problems with networks with win98 and winXP 
stations, the application was running with good performance almost of 
the time,
but in suddenly the performance slow down. We noticed that the problem 
was with the time to connect with the server, that was very slow.
The problem occurs also when the internet link down.
Well, I don't know why but when we exclude win98 stations from network, 
the problem disappears.
I think that was some DNS problem (but not sure), because one time we 
cleared nameserver clauses in the /etc/resolv.conf the performance 
return to the normal.
But we reinstalled win98 machines with winXP too, so I don't know what 
happened exactly.
The server OS was a Mandriva Linux running postgres ( 8.0, I guess) and 
samba. Workstations connect via odbc (informing the IP of server or the 
name to connect the problem persists).


-- 
Luiz K. Matsumura
Plan IT Tecnologia Informática Ltda.




From dave@tridecap.com Fri Sep  21 20:55:41 2007
Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 685119FB518
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:55:41 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 26216-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:55:39 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from globalrelay.com (mail1.globalrelay.com [204.92.49.200])
	by postgresql.org (Postfix) with ESMTP id 4373C9FA555
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 17:55:39 -0300 (ADT)
X-Virus-Scanned: Scanned by GRC-AntiVirus Gateway
Received: from [63.231.179.95] (HELO davedell)
	by globalrelay.com (CommuniGate Pro SMTP 4.2.3)
	with ESMTP id 158240760; Fri, 21 Sep 2007 20:55:37 +0000
From: "Dave Dutcher" <dave@tridecap.com>
To: <brauagustin-susc@yahoo.com.ar>
Cc: <pgsql-performance@postgresql.org>
References: <322942.8256.qm@web30004.mail.mud.yahoo.com>
Subject: Re: Low CPU Usage
Date: Fri, 21 Sep 2007 15:55:36 -0500
Message-ID: <023901c7fc91$c2a79ad0$cb00a8c0@tridecap.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acf8hxqTgmh+/N21RIStQui6h/d/BgACgz5A
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <322942.8256.qm@web30004.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/389
X-Sequence-Number: 26934


>From:  brauagustin-susc@yahoo.com.ar
>Subject: Re: [PERFORM] Low CPU Usage
>
>I have no idea how to continue researching this problem. Now I'm going to
do some networks tests.


I would go back to the slow program and try to capture the slow queries in
the log file.  Once you have some queries which are running slow then you
can run EXPLAIN ANALYZE to see what the bottle neck is.

It seems like you've found pgAdmin is slow sending across the network, but
we don't know if that has anything to do with your original problems.

Just my 2 cents.

Dave




From Kevin.Grittner@wicourts.gov Fri Sep  21 20:57:56 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 33C929FB5CF
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:57:56 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 53379-08 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 17:57:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by postgresql.org (Postfix) with ESMTP id 4A5A49FB5CD
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 17:57:51 -0300 (ADT)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Fri, 21 Sep 2007 15:57:49 -0500
Message-Id: <46F3E9ED.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.2 
Date: Fri, 21 Sep 2007 15:57:34 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Luiz K. Matsumura" <luiz@planit.com.br>, <brauagustin-susc@yahoo.com.ar>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: Low CPU Usage
References: <322942.8256.qm@web30004.mail.mud.yahoo.com>
	<46F42C54.7070901@planit.com.br>
In-Reply-To: <46F42C54.7070901@planit.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/390
X-Sequence-Number: 26935

>>> On Fri, Sep 21, 2007 at  3:40 PM, in message <46F42C54.7070901@planit.c=
om.br>,
"Luiz K. Matsumura" <luiz@planit.com.br> wrote:=20
=20
> but in suddenly the performance slow down. We noticed that the problem=20=

> was with the time to connect with the server, that was very slow.
=20
> I think that was some DNS problem (but not sure), because one time we=20
> cleared nameserver clauses in the /etc/resolv.conf the performance=20
> return to the normal.
=20
You may have it there.  In some versions of Java, on Windows, connection
times are horribly slow unless the machine's IP address has a reverse
DNS entry.  Perhaps the new machine lacks such an entry, or there's a
different version of Java in use?
=20
-Kevin
=20





From craig_james@emolecules.com Fri Sep  21 21:13:55 2007
Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id E05519FA1B5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 18:13:55 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 60208-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 18:13:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mail.emolecules.com (66-226-76-106.dedicated.abac.net
	[66.226.76.106])
	by postgresql.org (Postfix) with ESMTP id A46DC9FA150
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 18:13:49 -0300 (ADT)
Received: (qmail 21677 invoked by uid 2020); 21 Sep 2007 14:20:24 -0700
Received: from wsip-68-224-174-233.sd.sd.cox.net (HELO
	moonunit3.moonview.localnet) (68.224.174.233)
	by 192.168.0.4 with SMTP; 21 Sep 2007 14:20:23 -0700
Message-ID: <46F4347C.8010805@emolecules.com>
Date: Fri, 21 Sep 2007 14:15:40 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: "Luiz K. Matsumura" <luiz@planit.com.br>
CC: brauagustin-susc@yahoo.com.ar,  pgsql-performance@postgresql.org
Subject: Re: Low CPU Usage
References: <322942.8256.qm@web30004.mail.mud.yahoo.com>
	<46F42C54.7070901@planit.com.br>
In-Reply-To: <46F42C54.7070901@planit.com.br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.205 tagged_above=0 required=5 tests=AWL=0.104,
	BAYES_50=0.001, RDNS_DYNAMIC=0.1
X-Spam-Level: 
X-Archive-Number: 200709/391
X-Sequence-Number: 26936

Luiz K. Matsumura wrote:
>> Is connected to full 100Mb, it transfers many things quick to clients. 
>> Is running Apache adn JBoss, transfer rate is good, I did scp to copy 
>> many archives and is as quick as the old server.
>>
>> I have no idea how to continue researching this problem. Now I'm going 
>> to do some networks tests.

Any chance this is your desktop machine, and you're also using it for audio?  Microsoft built in a feature (!) that reduces network speed by 90% when music is playing:

  http://it.slashdot.org/article.pl?sid=07/08/26/1628200&from=rss

Craig



From brauagustin-susc@yahoo.com.ar Fri Sep  21 21:45:35 2007
Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id A88F69F9E59
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 18:45:35 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 32819-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 18:45:24 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30006.mail.mud.yahoo.com (web30006.mail.mud.yahoo.com
	[209.191.69.23]) by postgresql.org (Postfix) with SMTP id 596659F994A
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 18:45:28 -0300 (ADT)
Received: (qmail 50440 invoked by uid 60001); 21 Sep 2007 21:45:27 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=jKluKPNJOEr1ySW5WkB0E/mamB9fOnUAga4FFyZ7YKs4Y/HwwJdviCZ9BWR1VHu4CcFsqoxfstymeiTVSGN2A44TJP8X8CF0byoQvLnGYZcMLewylaxWzBDT3MmOKWnB83uZ1YmpnbW6snLYSBXjJi0aW7URWdlqBQrbYaI2aXM=;
X-YMail-OSG: 
 X6u3AKkVM1lkemr1e2eLU4ko7xsDb4TWNn4omnDMpCCae4iuiMjRtQsXtBmwZO4NEB_Mv0bZITwVciGYrcAJTVC1i1rcLukOJ1QJK_dkQFGhkdQ9fagl3noAIoQJew--
Received: from [209.191.106.126] by web30006.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 14:45:27 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 14:45:27 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Craig James <craig_james@emolecules.com>,
	"Luiz K. Matsumura" <luiz@planit.com.br>
Cc: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2022432705-1190411127=:50100"
Message-ID: <113513.50100.qm@web30006.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/392
X-Sequence-Number: 26937

--0-2022432705-1190411127=:50100
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

It's a Debian 4.0r1 server without sound (alsa is disabled), I'm running th=
e querys locally.=0AIt's happening running the query locally with PgAdmin a=
nd by jdbc locally too.=0AYes I have win98, XP machines on my network, I wi=
ll unplugged from the net and test again. On monday I'll give you my answer=
.=0ALast thing I did was disabling ipv6 and with the same results.=0A=0ATha=
nk you very much for your help.=0A=0A=0A----- Mensaje original ----=0ADe: C=
raig James <craig_james@emolecules.com>=0APara: Luiz K. Matsumura <luiz@pla=
nit.com.br>=0ACC: brauagustin-susc@yahoo.com.ar; pgsql-performance@postgres=
ql.org=0AEnviado: viernes 21 de septiembre de 2007, 18:15:40=0AAsunto: Re: =
[PERFORM] Low CPU Usage=0A=0ALuiz K. Matsumura wrote:=0A>> Is connected to =
full 100Mb, it transfers many things quick to clients. =0A>> Is running Apa=
che adn JBoss, transfer rate is good, I did scp to copy =0A>> many archives=
 and is as quick as the old server.=0A>>=0A>> I have no idea how to continu=
e researching this problem. Now I'm going =0A>> to do some networks tests.=
=0A=0AAny chance this is your desktop machine, and you're also using it for=
 audio?  Microsoft built in a feature (!) that reduces network speed by 90%=
 when music is playing:=0A=0A  http://it.slashdot.org/article.pl?sid=3D07/0=
8/26/1628200&from=3Drss=0A=0ACraig=0A=0A=0A=0A=0A=0A=0A=0A      Las =FAltim=
as noticias sobre el Mundial de Rugby 2007 est=E1n en Yahoo! Deportes. =A1C=
onocelas!=0Ahttp://ar.sports.yahoo.com/mundialderugby
--0-2022432705-1190411127=:50100
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">It's a Debian 4.0r1 server without sound (alsa is d=
isabled), I'm running the querys locally.<br>It's happening running the que=
ry locally with PgAdmin and by jdbc locally too.<br>Yes I have win98, XP ma=
chines on my network, I will unplugged from the net and test again. On mond=
ay I'll give you my answer.<br>Last thing I did was disabling ipv6 and with=
 the same results.<br><br>Thank you very much for your help.<br><br><br><di=
v style=3D"font-family: times new roman,new york,times,serif; font-size: 12=
pt;">----- Mensaje original ----<br>De: Craig James &lt;craig_james@emolecu=
les.com&gt;<br>Para: Luiz K. Matsumura &lt;luiz@planit.com.br&gt;<br>CC: br=
auagustin-susc@yahoo.com.ar; pgsql-performance@postgresql.org<br>Enviado:
 viernes 21 de septiembre de 2007, 18:15:40<br>Asunto: Re: [PERFORM] Low CP=
U Usage<br><br><div>Luiz K. Matsumura wrote:<br>&gt;&gt; Is connected to fu=
ll 100Mb, it transfers many things quick to clients. <br>&gt;&gt; Is runnin=
g Apache adn JBoss, transfer rate is good, I did scp to copy <br>&gt;&gt; m=
any archives and is as quick as the old server.<br>&gt;&gt;<br>&gt;&gt; I h=
ave no idea how to continue researching this problem. Now I'm going <br>&gt=
;&gt; to do some networks tests.<br><br>Any chance this is your desktop mac=
hine, and you're also using it for audio?&nbsp;&nbsp;Microsoft built in a f=
eature (!) that reduces network speed by 90% when music is playing:<br><br>=
&nbsp;&nbsp;<a target=3D"_blank" href=3D"http://it.slashdot.org/article.pl?=
sid=3D07/08/26/1628200&amp;from=3Drss">http://it.slashdot.org/article.pl?si=
d=3D07/08/26/1628200&amp;from=3Drss</a><br><br>Craig<br></div></div><br></d=
iv></div><br>=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"-2">S=
egu=ED de cerca a la Selecci=F3n Argentina de Rugby<br>en el Mundial de Fra=
ncia 2007.<br>=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></h=
tml>
--0-2022432705-1190411127=:50100--



From gsmith@gregsmith.com Sat Sep  22 06:29:31 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 391969F9E04
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Sat, 22 Sep 2007 03:29:31 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 60119-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Sat, 22 Sep 2007 03:29:06 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from westnet.com (westnet.com [216.187.52.2])
	by postgresql.org (Postfix) with ESMTP id 057719F9DDB
	for <pgsql-performance@postgresql.org>;
	Sat, 22 Sep 2007 03:29:17 -0300 (ADT)
Received: from westnet.com (localhost [127.0.0.1])
	by westnet.com (8.14.0/8.14.0) with ESMTP id l8M6THDA013089;
	Sat, 22 Sep 2007 02:29:17 -0400 (EDT)
Received: from localhost (gsmith@localhost)
	by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id l8M6THmg013085;
	Sat, 22 Sep 2007 02:29:17 -0400 (EDT)
X-Authentication-Warning: westnet.com: gsmith owned process doing -bs
Date: Sat, 22 Sep 2007 02:29:17 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
X-X-Sender: gsmith@westnet.com
To: brauagustin-susc@yahoo.com.ar
cc: pgsql-performance@postgresql.org
Subject: Re: Low CPU Usage
In-Reply-To: <383851.67716.qm@web30009.mail.mud.yahoo.com>
Message-ID: <Pine.GSO.4.64.0709220220490.12312@westnet.com>
References: <383851.67716.qm@web30009.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/396
X-Sequence-Number: 26941

On Thu, 20 Sep 2007, brauagustin-susc@yahoo.com.ar wrote:

> Which other test can I do to find if this is a hardware, kernel o 
> postgres issue?

The little test hdparm does is not exactly a robust hard drive benchmark. 
If you want to rule out hard drive transfer speed issues, take at look at 
the tests suggested at 
http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm and 
see how your results compare to the single SATA disk example I give there.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



From brauagustin-susc@yahoo.com.ar Mon Sep  24 13:59:32 2007
Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id F215D9F9867
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 24 Sep 2007 10:59:32 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 80166-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 24 Sep 2007 10:59:28 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30015.mail.mud.yahoo.com (web30015.mail.mud.yahoo.com
	[209.191.69.32]) by postgresql.org (Postfix) with SMTP id 415719F972D
	for <pgsql-performance@postgresql.org>;
	Mon, 24 Sep 2007 10:59:28 -0300 (ADT)
Received: (qmail 18858 invoked by uid 60001); 24 Sep 2007 13:59:26 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=ohL2O9hkpwJdlu1ZdUfHG43654lzJmn97rWvBvYuoyDxLh7iFhb3ksmEawWyVVxvWAYo5MxKkgRPHEqRKPmHrw1XL66TzTl3+FZrTrE7Jr9CA2dN00oUMseOFaD+iqYc//Epq42nwvhS2Ae9s8IJnMw20ZO/Z/Y3aFOMoHB/GME=;
X-YMail-OSG: 
 JXS7A2cVM1kJVbwi3jr.DJ2ZZ1s_d2ZbLRo.PqyLWQ9qUy0K6y6GFpsAp70f6Re_8hH6jTuQ_nV_yv0p3qNqBgmCGDj.tggtMMgOuObdIY_SnwIFb0M-
Received: from [209.191.106.127] by web30015.mail.mud.yahoo.com via HTTP;
	Mon, 24 Sep 2007 06:59:26 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Mon, 24 Sep 2007 06:59:26 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-236159941-1190642366=:18731"
Message-ID: <425702.18731.qm@web30015.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/414
X-Sequence-Number: 26959

--0-236159941-1190642366=:18731
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Greg this is my Bonnie result.=0A=0AVersion  1.03       ------Sequential=
 Output------ --Sequential Input- --Random-=0A                    -Per Chr-=
 --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--=0AMachine        Size K/=
sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP=0Ainsaubi        =
  8G 25893  54 26762   9 14146   3 36846  68 43502   3 102.8   0=0A        =
            ------Sequential Create------ --------Random Create--------=0A =
                   -Create-- --Read--- -Delete-- -Create-- --Read--- -Delet=
e--=0A              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=
  /sec %CP=0A                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ ++=
+++ +++ +++++ +++=0Ainsaubi,8G,25893,54,26762,9,14146,3,36846,68,43502,3,10=
2.8,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++=0A=0AI=
f I compare this against my laptop (SATA disk too) is really better, but I =
don't know if this result is a good one or not.=0AI don't know where to con=
tinue looking for the cause of the problem, I think there is a bug or somet=
hing missconfigured with Debian 4.0r1 and Postgres.=0AI unppluged the serve=
r from the network with the same results. I have the server mapped as local=
host in PgAdmin III, there shouldn't be network traffic and there isn't (mo=
nitoring the network interface). I'm really lost with this weird behaviour.=
=0AI really apreciate your help=0ARegards=0AAgustin=0A=0A----- Mensaje orig=
inal ----=0ADe: Greg Smith <gsmith@gregsmith.com>=0APara: brauagustin-susc@=
yahoo.com.ar=0ACC: pgsql-performance@postgresql.org=0AEnviado: s=E1bado 22 =
de septiembre de 2007, 3:29:17=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AO=
n Thu, 20 Sep 2007, brauagustin-susc@yahoo.com.ar wrote:=0A=0A> Which other=
 test can I do to find if this is a hardware, kernel o =0A> postgres issue?=
=0A=0AThe little test hdparm does is not exactly a robust hard drive benchm=
ark. =0AIf you want to rule out hard drive transfer speed issues, take at l=
ook at =0Athe tests suggested at =0Ahttp://www.westnet.com/~gsmith/content/=
postgresql/pg-disktesting.htm and =0Asee how your results compare to the si=
ngle SATA disk example I give there.=0A=0A--=0A* Greg Smith gsmith@gregsmit=
h.com http://www.gregsmith.com Baltimore, MD=0A=0A=0A=0A=0A=0A=0A=0A      L=
as =FAltimas noticias sobre el Mundial de Rugby 2007 est=E1n en Yahoo! Depo=
rtes. =A1Conocelas!=0Ahttp://ar.sports.yahoo.com/mundialderugby
--0-236159941-1190642366=:18731
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">Hi Greg this is my Bonnie result.<br><br>Version&nb=
sp; 1.03&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ------Sequential Output------ =
--Sequential Input- --Random-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -P=
er Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--<br>Machine&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Size K/sec %CP K/sec %CP K/sec %CP K/se=
c %CP K/sec %CP&nbsp; /sec %CP<br>insaubi&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 8G 25893&nbsp; 54 26762&nbsp;&nbsp; 9 14146&nbsp;&nbsp=
; 3 36846&nbsp; 68 43502&nbsp;&nbsp; 3 102.8&nbsp;&nbsp;
 0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ------Sequential Create------=
 --------Random Create--------<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -=
Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; files&nbs=
p; /sec %CP&nbsp; /sec %CP&nbsp; /sec %CP&nbsp; /sec %CP&nbsp; /sec %CP&nbs=
p; /sec %CP<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16 +++++ +++ +++++ +++ +++++ +++ +++++=
 +++ +++++ +++ +++++ +++<br>insaubi,8G,25893,54,26762,9,14146,3,36846,68,43=
502,3,102.8,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,++=
+<br><br>If I compare this against my laptop (SATA disk too) is really bett=
er, but I don't know if this result is a good one or not.<br>I don't
 know where to continue looking for the cause of the problem, I think there=
 is a bug or something missconfigured with Debian 4.0r1 and Postgres.<br>I =
unppluged the server from the network with the same results. I have the ser=
ver mapped as localhost in PgAdmin III, there shouldn't be network traffic =
and there isn't (monitoring the network interface). I'm really lost with th=
is weird behaviour.<br>I really apreciate your help<br>Regards<br>Agustin<b=
r><br><div style=3D"font-family: times new roman,new york,times,serif; font=
-size: 12pt;">----- Mensaje original ----<br>De: Greg Smith &lt;gsmith@greg=
smith.com&gt;<br>Para: brauagustin-susc@yahoo.com.ar<br>CC: pgsql-performan=
ce@postgresql.org<br>Enviado: s=E1bado 22 de septiembre de 2007, 3:29:17<br=
>Asunto: Re: [PERFORM] Low CPU Usage<br><br><div>On Thu, 20 Sep 2007, braua=
gustin-susc@yahoo.com.ar wrote:<br><br>&gt; Which other test can I do to fi=
nd if this is a hardware, kernel o <br>&gt; postgres issue?<br><br>The
 little test hdparm does is not exactly a robust hard drive benchmark. <br>=
If you want to rule out hard drive transfer speed issues, take at look at <=
br>the tests suggested at <br><a target=3D"_blank" href=3D"http://www.westn=
et.com/%7Egsmith/content/postgresql/pg-disktesting.htm">http://www.westnet.=
com/~gsmith/content/postgresql/pg-disktesting.htm</a> and <br>see how your =
results compare to the single SATA disk example I give there.<br><br>--<br>=
* Greg Smith gsmith@gregsmith.com <a target=3D"_blank" href=3D"http://www.g=
regsmith.com">http://www.gregsmith.com</a> Baltimore, MD<br></div></div><br=
></div></div><br>=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"-=
2">El Mundial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deportes:<b=
r>=0Ahttp://ar.sports.yahoo.com/mundialderugby</font></body></html>
--0-236159941-1190642366=:18731--



From brauagustin-susc@yahoo.com.ar Mon Sep  24 14:16:51 2007
Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 41FB49F99EA
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 24 Sep 2007 11:16:51 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 89376-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon, 24 Sep 2007 11:16:35 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30001.mail.mud.yahoo.com (web30001.mail.mud.yahoo.com
	[209.191.69.18]) by postgresql.org (Postfix) with SMTP id ADC2E9F983B
	for <pgsql-performance@postgresql.org>;
	Mon, 24 Sep 2007 11:16:43 -0300 (ADT)
Received: (qmail 37196 invoked by uid 60001); 24 Sep 2007 14:16:39 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar;
	h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID;
	b=XI7lQGwyzgBvSTDJYN14zMKsvunUmaR4M3IgmrDOppbm5LpbHCb8Mb1YvKpGvxOtKwb9Wq4fro//d5ATsRRqnHzyKgGUhSq2JtgkYpo5zXE2T+wdPjg9olyvj9sfZJJyuCPM0DikfIk1jEGnvMvS0sJlZpxHaC7RkOKD42TQhKo=;
X-YMail-OSG: 
 dtNamMoVM1k3V4RhW_gLEpulYQYG63Q1ELWOQQS_6JX7tENs7Eki.bGZ9p7DA3YLfZi6m3Qx4lUpBcqSVe6QxkHR1fYQgzhUDGNkaHPAKwjF9xJWDXQ-
Received: from [209.191.106.123] by web30001.mail.mud.yahoo.com via HTTP;
	Mon, 24 Sep 2007 07:16:38 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Mon, 24 Sep 2007 07:16:38 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-397900092-1190643398=:36392"
Message-ID: <129819.36392.qm@web30001.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/417
X-Sequence-Number: 26962

--0-397900092-1190643398=:36392
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I have found the reason!!! I begin to see line by line postgresql.conf and =
saw ssl =3D true.=0AI have disabled ssl and then I have restarted the serve=
r and that's all. It's 4 or 5 times faster than the old server.=0AI don't u=
nderstand why PgAdmin is connecting using ssl if I have leave this field em=
pty!!!=0ADebian by default installs Postgres with ssl enabled.=0AThank you =
very much all of you to help me to find the causes.=0ARegards=0AAgustin=0A=
=0A----- Mensaje original ----=0ADe: "brauagustin-susc@yahoo.com.ar" <braua=
gustin-susc@yahoo.com.ar>=0APara: Greg Smith <gsmith@gregsmith.com>=0ACC: p=
gsql-performance@postgresql.org=0AEnviado: lunes 24 de septiembre de 2007, =
10:59:26=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AHi Greg this is my Bonn=
ie result.=0A=0AVersion  1.03       ------Sequential Output------ --Sequent=
ial Input- --Random-=0A                    -Per Chr- --Block-- -Rewrite- -P=
er Chr- --Block-- --Seeks--=0AMachine        Size K/sec %CP K/sec %CP K/sec=
 %CP K/sec %CP K/sec %CP  /sec %CP=0Ainsaubi          8G 25893  54 26762   =
9 14146   3 36846  68 43502   3 102.8  =0A 0=0A                    ------Se=
quential Create------ --------Random Create--------=0A                    -=
Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--=0A              =
files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP=0A       =
          16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++=0A=
insaubi,8G,25893,54,26762,9,14146,3,36846,68,43502,3,102.8,0,16,+++++,+++,+=
++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++=0A=0AIf I compare this aga=
inst my laptop (SATA disk too) is really better, but I don't know if this r=
esult is a good one or not.=0AI don't=0A know where to continue looking for=
 the cause of the problem, I think there is a bug or something missconfigur=
ed with Debian 4.0r1 and Postgres.=0AI unppluged the server from the networ=
k with the same results. I have the server mapped as localhost in PgAdmin I=
II, there shouldn't be network traffic and there isn't (monitoring the netw=
ork interface). I'm really lost with this weird behaviour.=0AI really aprec=
iate your help=0ARegards=0AAgustin=0A=0A----- Mensaje original ----=0ADe: G=
reg Smith <gsmith@gregsmith.com>=0APara: brauagustin-susc@yahoo.com.ar=0ACC=
: pgsql-performance@postgresql.org=0AEnviado: s=E1bado 22 de septiembre de =
2007, 3:29:17=0AAsunto: Re: [PERFORM] Low CPU Usage=0A=0AOn Thu, 20 Sep 200=
7, brauagustin-susc@yahoo.com.ar wrote:=0A=0A> Which other test can I do to=
 find if this is a hardware, kernel o =0A> postgres issue?=0A=0AThe=0A litt=
le test hdparm does is not exactly a robust hard drive benchmark. =0AIf you=
 want to rule out hard drive transfer speed issues, take at look at =0Athe =
tests suggested at =0Ahttp://www.westnet.com/~gsmith/content/postgresql/pg-=
disktesting.htm and =0Asee how your results compare to the single SATA disk=
 example I give there.=0A=0A--=0A* Greg Smith gsmith@gregsmith.com http://w=
ww.gregsmith.com Baltimore, MD=0A=0A=0A=0A=0A=0A=0A=0A      =0AEl Mundial d=
e Rugby 2007=0ALas =FAltimas noticias en Yahoo! Deportes:=0A=0Ahttp://ar.sp=
orts.yahoo.com/mundialderugby=0A=0A=0A=0A=0A=0A      Los referentes m=E1s i=
mportantes en compra/ venta de autos se juntaron:=0ADemotores y Yahoo!=0AAh=
ora comprar o vender tu auto es m=E1s f=E1cil. Vist=E1 ar.autos.yahoo.com/
--0-397900092-1190643398=:36392
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;">I have found the reason!!! I begin to see line by l=
ine postgresql.conf and saw ssl =3D true.<br>I have disabled ssl and then I=
 have restarted the server and that's all. It's 4 or 5 times faster than th=
e old server.<br>I don't understand why PgAdmin is connecting using ssl if =
I have leave this field empty!!!<br>Debian by default installs Postgres wit=
h ssl enabled.<br>Thank you very much all of you to help me to find the cau=
ses.<br>Regards<br>Agustin<br><br><div style=3D"font-family: times new roma=
n,new york,times,serif; font-size: 12pt;">----- Mensaje original ----<br>De=
: "brauagustin-susc@yahoo.com.ar" &lt;brauagustin-susc@yahoo.com.ar&gt;<br>=
Para: Greg Smith &lt;gsmith@gregsmith.com&gt;<br>CC:
 pgsql-performance@postgresql.org<br>Enviado: lunes 24 de septiembre de 200=
7, 10:59:26<br>Asunto: Re: [PERFORM] Low CPU Usage<br><br><div style=3D"fon=
t-family: times new roman,new york,times,serif; font-size: 12pt;"><div styl=
e=3D"font-family: times new roman,new york,times,serif; font-size: 12pt;">H=
i Greg this is my Bonnie result.<br><br>Version&nbsp; 1.03&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; ------Sequential Output------ --Sequential Input- --Ran=
dom-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Per Chr- --Block-- -Rewrit=
e- -Per Chr- --Block-- --Seeks--<br>Machine&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP&nbsp; /se=
c %CP<br>insaubi&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8G 2=
5893&nbsp; 54 26762&nbsp;&nbsp; 9 14146&nbsp;&nbsp; 3 36846&nbsp; 68 43502&=
nbsp;&nbsp; 3 102.8&nbsp;&nbsp;=0A 0<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; ------Sequential Create------ --------Random Create--------<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Create-- --Read--- -Delete-- -Create-- --=
Read--- -Delete--<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; files&nbsp; /sec %CP&nbsp; /sec %CP&nbsp; /sec %CP=
&nbsp; /sec %CP&nbsp; /sec %CP&nbsp; /sec %CP<br>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16 +=
++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++<br>insaubi,8G,25=
893,54,26762,9,14146,3,36846,68,43502,3,102.8,0,16,+++++,+++,+++++,+++,++++=
+,+++,+++++,+++,+++++,+++,+++++,+++<br><br>If I compare this against my lap=
top (SATA disk too) is really better, but I don't know if this result is a =
good one or not.<br>I don't=0A know where to continue looking for the cause=
 of the problem, I think there is a bug or something missconfigured with De=
bian 4.0r1 and Postgres.<br>I unppluged the server from the network with th=
e same results. I have the server mapped as localhost in PgAdmin III, there=
 shouldn't be network traffic and there isn't (monitoring the network inter=
face). I'm really lost with this weird behaviour.<br>I really apreciate you=
r help<br>Regards<br>Agustin<br><br><div style=3D"font-family: times new ro=
man,new york,times,serif; font-size: 12pt;">----- Mensaje original ----<br>=
De: Greg Smith &lt;gsmith@gregsmith.com&gt;<br>Para: brauagustin-susc@yahoo=
.com.ar<br>CC: pgsql-performance@postgresql.org<br>Enviado: s=E1bado 22 de =
septiembre de 2007, 3:29:17<br>Asunto: Re: [PERFORM] Low CPU Usage<br><br><=
div>On Thu, 20 Sep 2007, brauagustin-susc@yahoo.com.ar wrote:<br><br>&gt; W=
hich other test can I do to find if this is a hardware, kernel o <br>&gt; p=
ostgres issue?<br><br>The=0A little test hdparm does is not exactly a robus=
t hard drive benchmark. <br>If you want to rule out hard drive transfer spe=
ed issues, take at look at <br>the tests suggested at <br><a rel=3D"nofollo=
w" target=3D"_blank" href=3D"http://www.westnet.com/%7Egsmith/content/postg=
resql/pg-disktesting.htm">http://www.westnet.com/~gsmith/content/postgresql=
/pg-disktesting.htm</a> and <br>see how your results compare to the single =
SATA disk example I give there.<br><br>--<br>* Greg Smith gsmith@gregsmith.=
com <a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.gregsmith.com"=
>http://www.gregsmith.com</a> Baltimore, MD<br></div></div><br></div></div>=
<br>=0A      <hr size=3D"1"><br><font face=3D"Verdana" size=3D"-2">El Mundi=
al de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deportes:<br><span>=0A=
<a target=3D"_blank" href=3D"http://ar.sports.yahoo.com/mundialderugby">htt=
p://ar.sports.yahoo.com/mundialderugby</a></span></font></div><br></div></d=
iv><br>=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"-2">El Mund=
ial de Rugby 2007<br>Las =FAltimas noticias en Yahoo! Deportes:<br>=0Ahttp:=
//ar.sports.yahoo.com/mundialderugby</font></body></html>
--0-397900092-1190643398=:36392--