Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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..


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

In response to


pgsql-performance by date

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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group