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
