Re: Postgresql and xeon.

Lists: pgsql-performance
From: "Eric Lauzon" <eric(dot)lauzon(at)abovesecurity(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Postgresql and xeon.
Date: 2005-05-30 13:43:12
Message-ID: F7B73864DD39FA40B6C56B3CE0D4D1CB634479@asdc003.abovesecurite.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

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


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Eric Lauzon" <eric(dot)lauzon(at)abovesecurity(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql and xeon.
Date: 2005-05-30 16:19:40
Message-ID: 200505300919.40827.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

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


From: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql and xeon.
Date: 2005-05-30 16:54:47
Message-ID: 20050530165447.GA9708@uio.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

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/


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql and xeon.
Date: 2005-05-30 17:15:08
Message-ID: 24603.1117473308@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-performance

"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)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