Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-31 Thread Dirk Lutzebäck
Anybody knows if RedHat is already supporting this patch on an 
enterprise version?


Regards,

Dirk



J. Andrew Rogers wrote:

On 7/29/05 10:46 AM, Josh Berkus josh@agliodbs.com wrote:


does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)?


Nope.   I suspect that you may be the first person to report in on
dual-cores.  There may be special compile issues with dual-cores that
we've not yet encountered.




There was recently a discussion of similar types of problems on a couple of
the supercomputing lists, regarding surprisingly substandard performance
from large dual-core opteron installations.

The problem as I remember it boiled down to the Linux kernel handling
memory/process management very badly on large dual core systems --
pathological NUMA behavior.  However, this problem has apparently been fixed
in Linux v2.6.12+, and using the more recent kernel on large dual core
systems generated *massive* performance improvements on these systems for
the individuals with this issue.  Using the patched kernel, one gets the
performance most people were expecting.

The v2.6.12+ kernels are a bit new, but they contain a very important
performance patch for systems like the one above.  It would definitely be
worth testing if possible.


J. Andrew Rogers





---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-31 Thread Dirk Lutzebäck

Hi Jeff,

which box are you running precisely and which OS/kernel?

We need to run 32bit because we need failover to 32 bit XEON system 
(DL580). If this does not work out we probably need to switch to 64 bit 
(dump/restore) and run a nother 64bit failover box too.


Regards,

Dirk



Jeffrey W. Baker wrote:

On Fri, 2005-07-29 at 10:46 -0700, Josh Berkus wrote:


Dirk,



does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)?



I'm using dual 275s without problems.


Nope.   I suspect that you may be the first person to report in on 
dual-cores.  There may be special compile issues with dual-cores that 
we've not yet encountered.



Doubtful.  However you could see improvements using recent Linux kernel
code.  There have been some patches for optimizing scheduling and memory
allocations.

However, if you are running this machine in 32-bit mode, why did you
bother paying $14,000 for your CPUs?  You will get FAR better
performance in 64-bit mode.  64-bit mode will give you 30-50% better
performance on PostgreSQL loads, in my experience.  Also, if I remember
correctly, the 32-bit x86 kernel doesn't understand Opteron NUMA
topology, so you may be seeing poor memory allocation decisions.

-jwb


We run RHEL 3.0, 32bit and under high load it is a drag. We 
mostly run memory demanding queries. Context switches are pretty much

around 20.000 on the average, no cs spikes when we run many processes in
parallel. Actually we only see two processes in running state! When
there are only a few processes running context switches go much higher.
At the moment we are much slower that with a 4way XEON box (DL580).


Um, that was a bit incoherent.  Are you seeing a CS storm or aren't you?




---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP DL585

2005-07-29 Thread Josh Berkus
Dirk,

 does anybody have expierence with this machine (4x 875 dual core Opteron
 CPUs)?

Nope.   I suspect that you may be the first person to report in on 
dual-cores.  There may be special compile issues with dual-cores that 
we've not yet encountered.

 We run RHEL 3.0, 32bit and under high load it is a drag. We 
 mostly run memory demanding queries. Context switches are pretty much
 around 20.000 on the average, no cs spikes when we run many processes in
 parallel. Actually we only see two processes in running state! When
 there are only a few processes running context switches go much higher.
 At the moment we are much slower that with a 4way XEON box (DL580).

Um, that was a bit incoherent.  Are you seeing a CS storm or aren't you?

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-29 Thread Jeffrey W. Baker
On Fri, 2005-07-29 at 10:46 -0700, Josh Berkus wrote:
 Dirk,
 
  does anybody have expierence with this machine (4x 875 dual core Opteron
  CPUs)?

I'm using dual 275s without problems.

 Nope.   I suspect that you may be the first person to report in on 
 dual-cores.  There may be special compile issues with dual-cores that 
 we've not yet encountered.

Doubtful.  However you could see improvements using recent Linux kernel
code.  There have been some patches for optimizing scheduling and memory
allocations.

However, if you are running this machine in 32-bit mode, why did you
bother paying $14,000 for your CPUs?  You will get FAR better
performance in 64-bit mode.  64-bit mode will give you 30-50% better
performance on PostgreSQL loads, in my experience.  Also, if I remember
correctly, the 32-bit x86 kernel doesn't understand Opteron NUMA
topology, so you may be seeing poor memory allocation decisions.

-jwb

  We run RHEL 3.0, 32bit and under high load it is a drag. We 
  mostly run memory demanding queries. Context switches are pretty much
  around 20.000 on the average, no cs spikes when we run many processes in
  parallel. Actually we only see two processes in running state! When
  there are only a few processes running context switches go much higher.
  At the moment we are much slower that with a 4way XEON box (DL580).
 
 Um, that was a bit incoherent.  Are you seeing a CS storm or aren't you?
 

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster