Thread: Value of Quad vs. Dual Processor machine
We are getting ready to spec out a new machine and are wondering about the wisdom of buying a quad versus a dual processor machine. Seing as how postgres in not a threaded application, and this server will only be used for log/transaction analysis (it will only ever have a few large queries running). Is there any performance to be gained, and if so is it worth the large cost? Any thoughts/experience are much appreciated... -- Chris Field cfield@affinitysolutions.com Affinity Solutions Inc. 386 Park Avenue South Suite 1209 New York, NY 10016 (212) 685-8748 ext. 32
Attachment
On Tue, 2003-11-11 at 18:32, Chris Field wrote: > We are getting ready to spec out a new machine and are wondering about > the wisdom of buying a quad versus a dual processor machine. Seing as > how postgres in not a threaded application, and this server will only be > used for log/transaction analysis (it will only ever have a few large > queries running). Is there any performance to be gained, and if so is > it worth the large cost? Any thoughts/experience are much > appreciated... Since you're asking the question, I'll assume you don't have CPU intensive queries or monstrous loads. I'd probably invest in a Quad system with 2 chips in it (2 empty sockets) and put the difference in funds into a few extra GB of Ram or improved IO. In 6 months or a year, if you start doing longer or more complex queries, toss in the other 2 chips. So long as you don't hit a memory limit, it'll be fine.
On Tue, 11 Nov 2003, Rod Taylor wrote: > On Tue, 2003-11-11 at 18:32, Chris Field wrote: > > We are getting ready to spec out a new machine and are wondering about > > the wisdom of buying a quad versus a dual processor machine. Seing as > > how postgres in not a threaded application, and this server will only be > > used for log/transaction analysis (it will only ever have a few large > > queries running). Is there any performance to be gained, and if so is > > it worth the large cost? Any thoughts/experience are much > > appreciated... > > Since you're asking the question, I'll assume you don't have CPU > intensive queries or monstrous loads. > > I'd probably invest in a Quad system with 2 chips in it (2 empty > sockets) and put the difference in funds into a few extra GB of Ram or > improved IO. > > In 6 months or a year, if you start doing longer or more complex > queries, toss in the other 2 chips. So long as you don't hit a memory > limit, it'll be fine. Note that you want to carefully look at the difference in cost of the motherboard versus the CPUs. It's often the motherboard that raises the cost, not the CPUs so much. Although with Xeons, the CPUs are not cheap. The second issue is that Intel (and AMD probably) only guarantee proper performance from chips int he same batch, so you may wind up replacing the two working CPUs with two new ones to go with the other two you'll be buying, to make sure that they work together. My guess is that more CPUs aren't gonna help this problem a lot, so look more at fast RAM and lots of it, as well as a fast I/O subsystem. 2 CPUs should be plenty.
On 2003-11-11T17:40:14-0700, scott.marlowe wrote: > 2 CPUs should be plenty. for everyone? No, I must have been thinking of someone else :-) /Allan -- Allan Wind P.O. Box 2022 Woburn, MA 01888-0022 USA
Attachment
> On Tue, 11 Nov 2003, Rod Taylor wrote: > >> On Tue, 2003-11-11 at 18:32, Chris Field wrote: >> > We are getting ready to spec out a new machine and are wondering about >> > the wisdom of buying a quad versus a dual processor machine. Seing as >> > how postgres in not a threaded application, and this server will only >> be >> > used for log/transaction analysis (it will only ever have a few large >> > queries running). Is there any performance to be gained, and if so is >> > it worth the large cost? Any thoughts/experience are much >> > appreciated... >> >> Since you're asking the question, I'll assume you don't have CPU >> intensive queries or monstrous loads. >> >> I'd probably invest in a Quad system with 2 chips in it (2 empty >> sockets) and put the difference in funds into a few extra GB of Ram or >> improved IO. >> >> In 6 months or a year, if you start doing longer or more complex >> queries, toss in the other 2 chips. So long as you don't hit a memory >> limit, it'll be fine. > > Note that you want to carefully look at the difference in cost of the > motherboard versus the CPUs. It's often the motherboard that raises the > cost, not the CPUs so much. Although with Xeons, the CPUs are not cheap. > > The second issue is that Intel (and AMD probably) only guarantee proper > performance from chips int he same batch, so you may wind up replacing the > two working CPUs with two new ones to go with the other two you'll be > buying, to make sure that they work together. > > My guess is that more CPUs aren't gonna help this problem a lot, so look > more at fast RAM and lots of it, as well as a fast I/O subsystem. > > 2 CPUs should be plenty. I agree that the additional cpus won't help as much since I haven't found any benefits in terms of individual query speed for a quad vs. an smp on benchmarks I've run on test machines I was considering purchasing. Quads are also expensive - on similar architectures the quad was 20k vs 7k for the dual. > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
On Tue, 2003-11-11 at 17:32, Chris Field wrote: > We are getting ready to spec out a new machine and are wondering about > the wisdom of buying a quad versus a dual processor machine. Seing as > how postgres in not a threaded application, and this server will only be > used for log/transaction analysis (it will only ever have a few large > queries running). Is there any performance to be gained, and if so is > it worth the large cost? Any thoughts/experience are much > appreciated... Xeon or Opteron? The faster Opterons *really* blaze, especially in 64-bit mode. As others have said, though, RAM and I/O are most important. -- ----------------------------------------------------------------- Ron Johnson, Jr. ron.l.johnson@cox.net Jefferson, LA USA "As I like to joke, I may have invented it, but Microsoft made it popular" David Bradley, regarding Ctrl-Alt-Del
we are looking at Xeon, We are currently running it on a quad sun v880 compiled to be 64bit and have been getting dreadful performance. I don't think we really have much to gain from going 64bit. ----- Original Message ----- From: "Ron Johnson" <ron.l.johnson@cox.net> To: "PgSQL Performance ML" <pgsql-performance@postgresql.org> Sent: Tuesday, November 11, 2003 8:24 PM Subject: Re: [PERFORM] Value of Quad vs. Dual Processor machine > On Tue, 2003-11-11 at 17:32, Chris Field wrote: > > We are getting ready to spec out a new machine and are wondering about > > the wisdom of buying a quad versus a dual processor machine. Seing as > > how postgres in not a threaded application, and this server will only be > > used for log/transaction analysis (it will only ever have a few large > > queries running). Is there any performance to be gained, and if so is > > it worth the large cost? Any thoughts/experience are much > > appreciated... > > Xeon or Opteron? The faster Opterons *really* blaze, especially > in 64-bit mode. As others have said, though, RAM and I/O are most > important. > > -- > ----------------------------------------------------------------- > Ron Johnson, Jr. ron.l.johnson@cox.net > Jefferson, LA USA > > "As I like to joke, I may have invented it, but Microsoft made it > popular" > David Bradley, regarding Ctrl-Alt-Del > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > >
One thing I learned after spending about a week comparing the Athlon (2 ghz, 333 mhz frontside bus) and Xeon (2.4 ghz, 266 mhz frontside bus) platforms was that on average the select queries I was benchmarking ran 30% faster on the Athlon (this was with data cached in memory so may not apply to the larger data sets where I/O is the limiting factor.) I benchmarked against the Opteron 244 when it came out and it came in about the same as the Athlon (makes sense since both were 333 mhz memory). The results within +/- 5-10% that of the Athlon. From testing against a couple of other machines I noticed that the memory bus speeds were almost directly proportional to the query times under these conditions. Not sure how these compare against the quad sun but the AMD chips returned the select queries faster than the Xeons from the informal investigations I did. Definitely try it before you buy it if possible. -----Original Message----- From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Chris Field Sent: Tuesday, November 11, 2003 6:13 PM To: Ron Johnson; PgSQL Performance ML Subject: Re: [PERFORM] Value of Quad vs. Dual Processor machine we are looking at Xeon, We are currently running it on a quad sun v880 compiled to be 64bit and have been getting dreadful performance. I don't think we really have much to gain from going 64bit. ----- Original Message ----- From: "Ron Johnson" <ron.l.johnson@cox.net> To: "PgSQL Performance ML" <pgsql-performance@postgresql.org> Sent: Tuesday, November 11, 2003 8:24 PM Subject: Re: [PERFORM] Value of Quad vs. Dual Processor machine > On Tue, 2003-11-11 at 17:32, Chris Field wrote: > > We are getting ready to spec out a new machine and are wondering > > about the wisdom of buying a quad versus a dual processor machine. > > Seing as how postgres in not a threaded application, and this server > > will only be used for log/transaction analysis (it will only ever > > have a few large queries running). Is there any performance to be > > gained, and if so is it worth the large cost? Any > > thoughts/experience are much appreciated... > > Xeon or Opteron? The faster Opterons *really* blaze, especially in > 64-bit mode. As others have said, though, RAM and I/O are most > important. > > -- > ----------------------------------------------------------------- > Ron Johnson, Jr. ron.l.johnson@cox.net > Jefferson, LA USA > > "As I like to joke, I may have invented it, but Microsoft made it > popular" David Bradley, regarding Ctrl-Alt-Del > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
Fred Moyer wrote: > One thing I learned after spending about a week comparing the Athlon (2 > ghz, 333 mhz frontside bus) and Xeon (2.4 ghz, 266 mhz frontside bus) > platforms was that on average the select queries I was benchmarking ran > 30% faster on the Athlon (this was with data cached in memory so may not > apply to the larger data sets where I/O is the limiting factor.) > > I benchmarked against the Opteron 244 when it came out and it came in > about the same as the Athlon (makes sense since both were 333 mhz > memory). The results within +/- 5-10% that of the Athlon. From testing > against a couple of other machines I noticed that the memory bus speeds > were almost directly proportional to the query times under these > conditions. I remember a posting here about opteron, which essentially said, even if opteron works on par with athlon under few clients, as load increases it scales more than 50% better than athlons. So that could be another shot at it.Sorry, no handy URL here. Shridhar
On Tue, 11 Nov 2003 21:13:19 -0500 "Chris Field" <cfield@affinitysolutions.com> wrote: > we are looking at Xeon, We are currently running it on a quad sun v880 > compiled to be 64bit and have been getting dreadful performance. I > don't think we really have much to gain from going 64bit. > > By chance, are you running 7.3.4 on that sun? If so, try this: export CFLAGS=-02 ./configure and rebuild PG. Before 7.4 PG was build with _no_ optimization on Solaris. Recompiling gives __HUGE__ (notice the underscores) performance gains. And onto the dual vs quad. PG will only use 1 cpu / connection / query. So if your machine iwll have 1-2 queries running at a time those other 2 proc's will sit around idling. However if you are going to have a bunch going, 4 cpus will be most useful. One of hte nicest things to do for PG is more ram and fast IO. It really loves those things. good luck -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
As another post pointed out, you need to set cflags to get optimization under Solaris on that flavor of Postgresql. Also, Postgresql tends to get its best performance from the free unixes, Linux and BSD. those are available for Sun Sparcs, but postgresql in 64 bit mode on those boxes is still a bit cutting edge. It might be worth a try to set up the sun to dual boot to either BSD or Linux and test Postgresql under that environment to see how it works and compare it to Sun after you've set the cflags and recompiled. On Tue, 11 Nov 2003, Chris Field wrote: > we are looking at Xeon, We are currently running it on a quad sun v880 > compiled to be 64bit and have been getting dreadful performance. I don't > think we really have much to gain from going 64bit. > > > ----- Original Message ----- > From: "Ron Johnson" <ron.l.johnson@cox.net> > To: "PgSQL Performance ML" <pgsql-performance@postgresql.org> > Sent: Tuesday, November 11, 2003 8:24 PM > Subject: Re: [PERFORM] Value of Quad vs. Dual Processor machine > > > > On Tue, 2003-11-11 at 17:32, Chris Field wrote: > > > We are getting ready to spec out a new machine and are wondering about > > > the wisdom of buying a quad versus a dual processor machine. Seing as > > > how postgres in not a threaded application, and this server will only be > > > used for log/transaction analysis (it will only ever have a few large > > > queries running). Is there any performance to be gained, and if so is > > > it worth the large cost? Any thoughts/experience are much > > > appreciated... > > > > Xeon or Opteron? The faster Opterons *really* blaze, especially > > in 64-bit mode. As others have said, though, RAM and I/O are most > > important. > > > > -- > > ----------------------------------------------------------------- > > Ron Johnson, Jr. ron.l.johnson@cox.net > > Jefferson, LA USA > > > > "As I like to joke, I may have invented it, but Microsoft made it > > popular" > > David Bradley, regarding Ctrl-Alt-Del > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faqs/FAQ.html > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > >
On Wed, 2003-11-12 at 09:28, Jeff wrote:
> On Tue, 11 Nov 2003 21:13:19 -0500
> "Chris Field" <cfield@affinitysolutions.com> wrote:
>
> > we are looking at Xeon, We are currently running it on a quad sun v880
> > compiled to be 64bit and have been getting dreadful performance. I
> > don't think we really have much to gain from going 64bit.
> >
> >
> By chance, are you running 7.3.4 on that sun?
> If so, try this:
> export CFLAGS=-02
> ./configure
>
> and rebuild PG.
>
> Before 7.4 PG was build with _no_ optimization on Solaris.
> Recompiling gives __HUGE__ (notice the underscores) performance gains.
>
> And onto the dual vs quad.
>
> PG will only use 1 cpu / connection / query.
>
> So if your machine iwll have 1-2 queries running at a time those other 2
> proc's will sit around idling. However if you are going to have a bunch
> going, 4 cpus will be most useful. One of hte nicest things to do for
> PG is more ram and fast IO. It really loves those things.
>
We've just started kicking around the idea of moving one of our boxes to
a quad-proc machine from a dual. Under normal circumstances the 2
processors handle maybe 200 transactions per second with 90% system
idle. However we have people who occasionally run historical reports on
our data, and those reports are fairly CPU intensive. Usually it is not
a problem for the main web system, but when pg_dump is running, that is
also cpu intensive, so we end up with two highly cpu intensive items
running on our machine, and we start to notice issues on the main web
system.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL