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.
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... |
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 |