Message-ID: <42ECA3B6.3000607@aeccom.com>
Date: Sun, 31 Jul 2005 12:11:02 +0200
From: =?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <lutzeb@aeccom.com>
Reply-To: lutzeb@aeccom.com
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
MIME-Version: 1.0
To: "Jeffrey W. Baker" <jwbaker@acm.org>
Cc: josh@agliodbs.com, pgsql-performance@postgresql.org,
	Sven Geisler <sgeisler@aeccom.com>
Subject: Re: Performance problems on 4/8way Opteron (dualcore) HP
References: <42EA5D18.9020204@aeccom.com>	
	<200507291046.10318.josh@agliodbs.com>
	<1122663342.6814.5.camel@toonses.gghcwest.com>
In-Reply-To: <1122663342.6814.5.camel@toonses.gghcwest.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?
>>