Re: Wierd context-switching issue on Xeon

From: "Anjan Dave" <adave(at)vantage(dot)com>
To: "Greg Stark" <gsstark(at)mit(dot)edu>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <lutzeb(at)aeccom(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Neil Conway" <neilc(at)samurai(dot)com>
Subject: Re: Wierd context-switching issue on Xeon
Date: 2004-04-19 13:52:39
Message-ID: 4BAFBB6B9CC46F41B2AD7D9F4BBAF78509813F@vt-pe2550-001.vantage.vantage.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

What about quad-XEON setups? Could that be worse? (have dual, and quad setups both) Shall we re-consider XEON-MP CPU machines with high cache (4MB+)?

Very generally, what number would be considered high, especially, if it coincides with expected heavy load?

Not sure a specific chipset was mentioned...

Thanks,
Anjan

-----Original Message-----
From: Greg Stark [mailto:gsstark(at)mit(dot)edu]
Sent: Sun 4/18/2004 8:40 PM
To: Tom Lane
Cc: lutzeb(at)aeccom(dot)com; Josh Berkus; pgsql-performance(at)postgresql(dot)org; Neil Conway
Subject: Re: [PERFORM] Wierd context-switching issue on Xeon

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> So in the short term I think we have to tell people that Xeon MP is not
> the most desirable SMP platform to run Postgres on. (Josh thinks that
> the specific motherboard chipset being used in these machines might
> share some of the blame too. I don't have any evidence for or against
> that idea, but it's certainly possible.)
>
> In the long run, however, CPUs continue to get faster than main memory
> and the price of cache contention will continue to rise. So it seems
> that we need to give up the assumption that SpinLockAcquire is a cheap
> operation. In the presence of heavy contention it won't be.

There's nothing about the way Postgres spinlocks are coded that affects this?

Is it something the kernel could help with? I've been wondering whether
there's any benefits postgres is missing out on by using its own hand-rolled
locking instead of using the pthreads infrastructure that the kernel is often
involved in.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-04-19 16:00:10 Re: query slows down with more accurate stats
Previous Message Rod Taylor 2004-04-19 12:36:34 Re: very slow simple query - outer join makes it quicker