Re: Performance Issues on Opteron Dual Core - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: Performance Issues on Opteron Dual Core
Date
Msg-id 20060504174721.GM97354@pervasive.com
Whole thread Raw
In response to Re: Performance Issues on Opteron Dual Core  ("Gregory Stewart" <gstewart@sweetdata.com>)
Responses Re: Performance Issues on Opteron Dual Core  ("Gregory Stewart" <gstewart@sweetdata.com>)
List pgsql-performance
All the machines I've been able to replicate this on have been SMP w2k3
machines running SP1. I've been unable to replicate it on anything not
running w2k3, but the only 'SMP' machine I've tested in that manner was
an Intel with HT enabled. I now have an intel with HT and running w2k3
sitting in my office, but I haven't had a chance to fire it up and try
it yet. Once I test that machine it should help narrow down if this
problem exists with HT machines (which someone on -hackers mentioned
they had access to and could do testing with). If it does affect HT
machines then I suspect that this is not an issue for XP...

On Tue, May 02, 2006 at 11:27:02PM -0500, Gregory Stewart wrote:
> Jim,
>
> Have you seen this happening only on W2k3? I am wondering if I should try
> out 2000 Pro or XP Pro.
> Not my first choice, but if it works...
>
>
>
> -----Original Message-----
> From: Jim C. Nasby [mailto:jnasby@pervasive.com]
> Sent: Tuesday, May 02, 2006 3:29 PM
> To: Mark Kirkwood
> Cc: Gregory Stewart; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Performance Issues on Opteron Dual Core
>
>
> On Sun, Apr 30, 2006 at 10:59:56PM +1200, Mark Kirkwood wrote:
> > Pgadmin can give misleading times for queries that return large result
> > sets over a network, due to:
> >
> > 1/ It takes time to format the (large) result set for display.
> > 2/ It has to count the time spent waiting for the (large) result set to
> > travel across the network.
> >
> > You aren't running Pgadmin off the dev server are you? If not check your
> > network link to dev and prod  - is one faster than the other? (etc).
> >
> > To eliminate Pgadmin and the network as factors try wrapping your query
> > in a 'SELECT count(*) FROM (your query here) AS a', and see if it
> > changes anything!
>
> FWIW, I've found problems running PostgreSQL on Windows in a multi-CPU
> environment on w2k3. It runs fine for some period, and then CPU and
> throughput drop to zero. So far I've been unable to track down any more
> information than that, other than the fact that I haven't been able to
> reproduce this on any single-CPU machines.
> --
> Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
> Pervasive Software      http://pervasive.com    work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.5.1/328 - Release Date: 5/1/2006
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-performance by date:

Previous
From: Chris Mckenzie
Date:
Subject: Re: Postgres 7.4 and vacuum_cost_delay.
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Performance Issues on Opteron Dual Core