Re: Hardware recommendations to scale to silly load

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware recommendations to scale to silly load
Date: 2003-08-29 08:18:24
Message-ID: 3F4F59A8.20966.434E2AD@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On 29 Aug 2003 at 0:05, William Yu wrote:

> Shridhar Daithankar wrote:
> >> Be careful here, we've seen that with the P4 Xeon's that are
> >>hyper-threaded and a system that has very high disk I/O causes the
> >>system to be sluggish and slow. But after disabling the hyper-threading
> >>itself, our system flew..
> >
> > Anybody has opteron working? Hows' the performance?
>
> Yes. I'm using an 2x 1.8GHz Opteron system w/ 8GB of RAM. Right now, I'm
> still using 32-bit Linux -- I'm letting others be the 64-bit guinea
> pigs. :) I probably will get a cheapie 1x Opteron machine first and test
> the 64-bit kernel/libraries thoroughly before rolling it out to production.

Just a guess here but does a precompiled postgresql for x86 and a x86-64
optimized one makes difference?

Opteron is one place on earth you can watch difference between 32/64 bit on
same machine. Can be handy at times..

>
> As for performance, the scaling is magnificient -- even when just using
> PAE instead of 64-bit addressing. At low transaction counts, it's only
> ~75% faster than the 2x Athlon 1800+ MP it replaced. But once the
> transactions start coming in, the gap is as high as 5x. My w-a-g: since
> each CPU has an integrated memory controller, you avoid memory bus
> contention which is probably the major bottleneck as transaction load
> increases. (I've seen Opteron several vs Xeon comparisons where
> single-connection tests are par for both CPUs but heavy-load tests favor
> the Opteron by a wide margin.) I suspect the 4X comparisons would tilt
> even more towards AMD's favor.

I am sure. But is 64 bit environment, Xeon is not the compitition. It's PA-RSC-
8700, ultraSparcs, Power series and if possible itanium.

I would still expect AMD to compete comfortably given high clock speed. But
chipset need to be competent as well..

I still remember the product I work on, a single CPU PA-RISC 8700 with single
SCSI disc, edged out a quad CPU Xeon with SCSI RAID controller running windows
in terms of scalability while running oracle.

I am not sure if it was windows v/s HP-UX issue but at the end HP machine was
lot better than windows machine. Windows machine shooted ahead for light load
and drooeed dead equally fast with rise in load..

> We should see a boost when we move to 64-bit Linux and hopefully another
> one when NUMA for Linux is production-stable.

Getting a 2.6 running now is the answer to make it stable fast..:-) Of course
if you have spare hardware..

Bye
Shridhar

--
briefcase, n: A trial where the jury gets together and forms a lynching party.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2003-08-29 08:22:11 Re: ALTER TABLE
Previous Message Mark Kirkwood 2003-08-29 07:38:05 Re: Bumping block size to 16K on FreeBSD...

Browse pgsql-performance by date

  From Date Subject
Next Message Shridhar Daithankar 2003-08-29 08:30:34 Re: Queries sometimes take 1000 times the normal time
Previous Message Ken Geis 2003-08-29 08:17:25 Re: bad estimates