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