Re: Wierd context-switching issue on Xeon

Dirk Lutzebaeck <dirk.lutzebaeck@t-online.de>

From: Dirk.Lutzebaeck@t-online.de (Dirk Lutzebaeck)
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgreSQL.org, Neil Conway <neilc@samurai.com>
Date: 2004-04-19T21:18:27Z
Lists: pgsql-performance
I would agree to Tom, that too much parameters are involved to blame 
bigmem. I have access to the following machines where the same 
application operates:

a)  Dual (4way) XEON MP, bigmem, HT off, ServerWorks chipset (a 
Fujitsu-Siemens Primergy)

performs ok now because missing indexes were added but this is no proof 
that this behaviour occurs again under high load, context switches are 
moderate but have peaks to 40.000

b) Dual XEON DP, non-bigmem, HT on, ServerWorks chipset (a Dell machine 
I think)

performs moderate because I see too much context switches here although 
the mentioned indexes are created, context switches go up to 30.000 
often, I can see 50% semop calls

c) Dual XEON DP, non-bigmem, HT on, E7500 Intel chipset (Supermicro)

performs well and I could not observe context switch peaks here (one 
user active), almost no extra semop calls

d) Dual XEON DP, bigmem, HT off, ServerWorks chipset (a Fujitsu-Siemens 
Primergy)

performance unknown at the moment (is offline) but looks like a) in the past

I can offer to do tests on those machines if somebody would provide me 
some test instructions to nail this problem down.

Dirk



Tom Lane wrote:

>Josh Berkus <josh@agliodbs.com> writes:
>  
>
>>The other thing I'd like your comment on, Tom, is that Dirk appears to have 
>>reported that when he installed a non-bigmem kernel, the issue went away.   
>>Dirk, is this correct?
>>    
>>
>
>I'd be really surprised if that had anything to do with it.  AFAIR
>Dirk's test changed more than one variable and so didn't prove a
>connection.
>
>			regards, tom lane
>
>  
>