Re: IBM P-series machines (was: Excessive context - Mailing list pgsql-performance

From Christopher Browne
Subject Re: IBM P-series machines (was: Excessive context
Date
Msg-id m34ql0yb0r.fsf@knuth.knuth.cbbrowne.com
Whole thread Raw
In response to Excessive context switching on SMP Xeons  (Bill Montgomery <billm@lulu.com>)
Responses Re: IBM P-series machines
List pgsql-performance
pg@rbt.ca (Rod Taylor) wrote:
> On Mon, 2004-10-11 at 13:38, Andrew Sullivan wrote:
>> On Tue, Oct 05, 2004 at 09:47:36AM -0700, Josh Berkus wrote:
>> > As long as you're on x86, scaling outward is the way to go.  If
>> > you want to continue to scale upwards, ask Andrew Sullivan about
>> > his experiences running PostgreSQL on big IBM boxes.  But if you
>> > consider an quad-Opteron server expensive, I don't think that's
>> > an option for you.
>
>> The 650s are not cheap, but boy are they fast.  I don't have any
>> numbers I can share, but I can tell you that we recently had a few
>> days in which our write load was as large as the entire write load
>> for last year, and you couldn't tell.  It is too early for us to
>> say whether the P series lives up to its billing in terms of
>> relibility: the real reason we use these machines is reliability,
>> so if approaching 100% uptime isn't important to you, the speed may
>> not be worth it.
>
> Agreed completely, and the 570 knocks the 650 out of the water --
> nearly double the performance for math heavy queries. Beware vendor
> support for Linux on these things though -- we ran into many of the
> same issues with vendor support on the IBM machines as we did with
> the Opterons.

The 650s are running AIX, not Linux.

Based on the "Signal 11" issue, I'm not certain what would be the
'best' answer.  It appears that the problem relates to proprietary
bits of AIX libc.  In theory, that would have been more easily
resolvable with a source-available GLIBC.

On the other hand, I'm not sure what happens to support for any of the
interesting hardware extensions.  I'm not sure, for instance, that we
could run HACMP on Linux on this hardware.

As for "vendor support" for Opteron, that sure looks like a
trainwreck...  If you're going through IBM, then they won't want to
respond to any issues if you're not running a "bog-standard" RHAS/RHES
release from Red Hat.  And that, on Opteron, is preposterous, because
there's plenty of the bits of Opteron support that only ever got put
in Linux 2.6, whilst RHAT is still back in the 2.4 days.

In a way, that's just as well, at this point.  There's plenty of stuff
surrounding this that is still pretty experimental; the longer RHAT
waits to support 2.6, the greater the likelihood that Linux support
for Opteron will have settled down to the point that the result will
actually be supportable by RHAT, and by proxy, by IBM and others.

There is some risk that if RHAT waits _too_ long for 2.6, people will
have already jumped ship to SuSE.  No benefits without risks...
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/rdbms.html
If at first you don't succeed, then you didn't do it right!
If at first you don't succeed, then skydiving definitely isn't for you.

pgsql-performance by date:

Previous
From: Greg Stark
Date:
Subject: Re: why my query is not using index??
Next
From: Kris Jurka
Date:
Subject: Re: Normal case or bad query plan?