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.


Tom Lane wrote:

Josh Berkus <[EMAIL PROTECTED]> 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

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

Reply via email to