Обсуждение: Postgresql and xeon.
What about xeon and postgresql, i have been told that postgresql wouldn't perform as well when running under xeon processors due to some cache trick that postgresql uses? Why? Any fix? Rumors? AMD Advocates? Problems with HT?? Would that problems only be true for 7.4.x? I didin't found any comprehensive analysis/explanation for this matters beside people saying , stop using xeon and postgresql. Enlightment please... Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858
Eric, > What about xeon and postgresql, i have been told that > postgresql wouldn't perform as well when running > under xeon processors due to some cache trick that postgresql > uses? Search the archives of this list. This has been discussed ad nauseum. www.pgsql.ru -- Josh Berkus Aglio Database Solutions San Francisco
On Mon, May 30, 2005 at 09:19:40AM -0700, Josh Berkus wrote: > Search the archives of this list. This has been discussed ad nauseum. > www.pgsql.ru I must admit I still haven't really understood it -- I know that it appears on multiple operating systems, on multiple architectures, but most with Xeon CPUs, and that it's probably related to the poor memory bandwidth between the CPUs, but that's about it. I've read the threads I could find on the list archives, but I've yet to see somebody pinpoint exactly what in PostgreSQL is causing this. Last time someone claimed this was bascially understood and "just a lot of work to fix", I asked for pointers to a more detailed analysis, but nobody answered. Care to explain? :-) /* Steinar */ -- Homepage: http://www.sesse.net/
> -----Original Message----- > From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of > Steinar H. Gunderson > Sent: 30 mai 2005 12:55 > To: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Postgresql and xeon. > > On Mon, May 30, 2005 at 09:19:40AM -0700, Josh Berkus wrote: > > Search the archives of this list. This has been discussed > ad nauseum. > > www.pgsql.ru > > I must admit I still haven't really understood it -- I know > that it appears on multiple operating systems, on multiple > architectures, but most with Xeon CPUs, and that it's > probably related to the poor memory bandwidth between the > CPUs, but that's about it. I've read the threads I could find > on the list archives, but I've yet to see somebody pinpoint > exactly what in PostgreSQL is causing this. > > Last time someone claimed this was bascially understood and > "just a lot of work to fix", I asked for pointers to a more > detailed analysis, but nobody answered. Care to explain? :-) Same here archives references are just overview but no real data.... to where and why, i would state pg 7.4.8 and kernel 2.6 with preemptive scheduler and dual xeon 3.2 ghz 6 gig of ram. Eric Lauzon [Recherche & Développement] Above Sécurité / Above Security Tél : (450) 430-8166 Fax : (450) 430-1858
"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
> I must admit I still haven't really understood it -- I know that it appears
> on multiple operating systems, on multiple architectures, but most with Xeon
> CPUs, and that it's probably related to the poor memory bandwidth between the
> CPUs, but that's about it. I've read the threads I could find on the list
> archives, but I've yet to see somebody pinpoint exactly what in PostgreSQL is
> causing this.
The problem appears to be that heavy contention for a spinlock is
extremely expensive on multiprocessor Xeons --- apparently, the CPUs
waste tremendous amounts of time passing around exclusive ownership
of the memory cache line containing the spinlock. While any SMP system
is likely to have some issues here, the Xeons seem to be particularly
bad at it.
In the case that was discussed extensively last spring, the lock that
was causing the problem was the BufMgrLock. Since 8.0 we've rewritten
the buffer manager in hopes of reducing contention, but I don't know
if the problem is really gone or not. The buffer manager is hardly the
only place with the potential for heavy contention...
regards, tom lane