Thread: Re: [ADMIN] Benchmarking postgres on Solaris/Linux
We are looking into Sun V210 (2 x 1 GHz cpu, 2 gig ram, 5.8Os) vs. Dell 1750
(2 x 2.4 GHz xeon, 2 gig ram, RH3.0). database will mostly be
write intensive and disks will be on raid 10. Wondering if 64bit 1 GHz to
32bit 2.4 GHz make a big difference here.
Thanks!
-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Andrew
Sullivan
Sent: Tuesday, March 23, 2004 9:37 AM
To: 'pgsql-performance@postgresql.org'
Subject: Re: [PERFORM] [ADMIN] Benchmarking postgres on Solaris/Linux
On Mon, Mar 22, 2004 at 04:05:45PM -0800, Subbiah, Stalin wrote:
> being the key performance booster for postgres. what is the preferred OS
> for postgres deployment if given an option between linux and solaris. As
One thing this very much depends on is what you're trying to do.
Suns have a reputation for greater reliability. While my own
experience with Sun hardware has been rather shy of sterling, I _can_
say that it stands head and shoulders above a lot of the x86 gear you
can get.
If you're planning to use Solaris on x86, don't bother. Solaris is a
slow, bloated pig compared to Linux, at least when it comes to
managing the largish number of processes that Postgres requires.
If pure speed is what you're after, I have found that 2-way, 32 bit
Linux on P-IIIs compares very favourably to 4 way 64 bit Ultra SPARC
IIs.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the
marketplace.
--Philip Greenspun
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
If it's going to be write intensive then the RAID controller will be the most important thing. A dual p3/500 with a write-back cache will smoke either of the boxes you mention using software RAID on write performance. As for the compute intensive side (complex joins & sorts etc), the Dell will most likely beat the Sun by some distance, although what the Sun lacks in CPU power it may make up a bit in memory bandwidth/latency. Matt > -----Original Message----- > From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Subbiah, > Stalin > Sent: 23 March 2004 18:41 > To: 'Andrew Sullivan'; 'pgsql-performance@postgresql.org' > Subject: Re: [PERFORM] [ADMIN] Benchmarking postgres on Solaris/Linux > > > We are looking into Sun V210 (2 x 1 GHz cpu, 2 gig ram, 5.8Os) vs. Dell 1750 > (2 x 2.4 GHz xeon, 2 gig ram, RH3.0). database will mostly be > write intensive and disks will be on raid 10. Wondering if 64bit 1 GHz to > 32bit 2.4 GHz make a big difference here. > > Thanks! > > -----Original Message----- > From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Andrew > Sullivan > Sent: Tuesday, March 23, 2004 9:37 AM > To: 'pgsql-performance@postgresql.org' > Subject: Re: [PERFORM] [ADMIN] Benchmarking postgres on Solaris/Linux > > > On Mon, Mar 22, 2004 at 04:05:45PM -0800, Subbiah, Stalin wrote: > > being the key performance booster for postgres. what is the preferred OS > > for postgres deployment if given an option between linux and solaris. As > > One thing this very much depends on is what you're trying to do. > Suns have a reputation for greater reliability. While my own > experience with Sun hardware has been rather shy of sterling, I _can_ > say that it stands head and shoulders above a lot of the x86 gear you > can get. > > If you're planning to use Solaris on x86, don't bother. Solaris is a > slow, bloated pig compared to Linux, at least when it comes to > managing the largish number of processes that Postgres requires. > > If pure speed is what you're after, I have found that 2-way, 32 bit > Linux on P-IIIs compares very favourably to 4 way 64 bit Ultra SPARC > IIs. > > A > > -- > Andrew Sullivan | ajs@crankycanuck.ca > The fact that technology doesn't work is no bar to success in the > marketplace. > --Philip Greenspun > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match >
Matt, Stalin, > As for the compute intensive side (complex joins & sorts etc), the Dell will most likely beat the Sun by some distance, although > what the Sun lacks in CPU power it may make up a bit in memory bandwidth/ latency. Personally, I've been unimpressed by Dell/Xeon; I think the Sun might do better than you think, comparitively. On all the Dell servers I've used so far, I've not seen performance that comes even close to the hardware specs. -- -Josh Berkus Aglio Database Solutions San Francisco
On Tue, 23 Mar 2004, Josh Berkus wrote: > Matt, Stalin, > > > As for the compute intensive side (complex joins & sorts etc), the Dell will > most likely beat the Sun by some distance, although > > what the Sun lacks in CPU power it may make up a bit in memory bandwidth/ > latency. > > Personally, I've been unimpressed by Dell/Xeon; I think the Sun might do > better than you think, comparitively. On all the Dell servers I've used so > far, I've not seen performance that comes even close to the hardware specs. We use a 2600 at work (dual 2.8GHz) with the LSI/Megaraid based battery backed caching controller, and it flies. Truly flies. It's not Dell that's so slow, it's the default adaptec RAID controller or IDE drives that are slow. Ours has 533 MHz memory bus, by the way.
> Personally, I've been unimpressed by Dell/Xeon; I think the Sun might do > better than you think, comparitively. On all the Dell servers I've used > so > far, I've not seen performance that comes even close to the hardware > specs. It's true that any difference will be far less than the GHz ratio, and I can't really speak for Dell servers in general, but a pair of 2.4GHz Xeons in a Dell workstation gets about 23 SPECint_rate2000, and a pair of 1GHz UltraSparc IIIs in a SunFire V210 gets 10. The ratios are the same for other non-FP benchmarks. Now the Suns do have some architectural advantages, and they used to have far superior memory bandwidth than intel boxes, and they often still do for more than 2 cpus, and definitely do for more than four. But my personal experience is that for 4 cpus or less the entry level UNIX offerings from Sun/IBM/HP fell behind in raw performance (FP excepted) two or three years ago. The posh hardware's an entirely different matter of course. On the other hand, I can think of innumerable non performance related reasons to buy a 'real UNIX box' as a low end DB server. CPU performance is way down the priority list compared with IO throughput, stability, manageability, support, etc etc. Given that the original question was about a very heavily write-oriented environment, I'd take the Sun every day of the week, assuming that those compile option changes have sorted out the oddly slow PG performance at last. M
On Tue, Mar 23, 2004 at 08:53:42PM -0000, matt@ymogen.net wrote:
> is way down the priority list compared with IO throughput, stability,
> manageability, support, etc etc.
Indeed, if our Suns actually diabled the broken hardware when they
died, fell over, and rebooted themselves, I'd certainly praise them
to heaven. But I have to say that the really very good reporting of
failing memory has saved me some headaches.
> environment, I'd take the Sun every day of the week, assuming that those
> compile option changes have sorted out the oddly slow PG performance at
> last.
I seem to have hit a bad batch of Dell hardware recently, which makes
me second this opinion.
I should say, also, that my initial experience of AIX has been
extremely good. I can't comment on the fun it might involve in the
long haul, of course.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie
> Indeed, if our Suns actually diabled the broken hardware when they > died, fell over, and rebooted themselves, I'd certainly praise them > to heaven. But I have to say that the really very good reporting of > failing memory has saved me some headaches. Ha! Yes, it would seem the obvious thing to do - but as you say, at least you get told what borked and may even be able to remove it without stopping the machine. Sometimes. Or at least you get a nice lunch from your Sun reseller. > I should say, also, that my initial experience of AIX has been > extremely good. I can't comment on the fun it might involve in the > long haul, of course. The current crop of power4+ boxen is reputed to even be able to recover from a failed CPU without a restart. Not *always* one imagines, but usefully often enough for the banking mob to get sweaty over the feature. More importantly though, IBM seems committed to supporting all this goodness under Linux too (though not BSD I fear - sorry Bruce) Now if these vendors could somehow eliminate downtime due to human error we'd be talking *serious* reliablity. M
On Tue, Mar 23, 2004 at 11:35:47PM -0000, matt@ymogen.net wrote:
> More importantly though, IBM seems committed to supporting all this
> goodness under Linux too (though not BSD I fear - sorry Bruce)
Although so far they don't. And let me tell you, AIX's reputation
for being strange is well earned. It has some real nice features,
though: topas is awfully nice for spotting bottlenecks, and it works
in a terminal so you don't have to have X and all the rest of that
stuff installed. We're just in the preliminary stages with this
system, but my experience so far has been positive. On new machines,
though, one _hopes_ that hardware failures are relatively infrequent.
> Now if these vendors could somehow eliminate downtime due to human error
> we'd be talking *serious* reliablity.
You mean making the OS smart enough to know when clearing the arp
cache is a bonehead operation, or just making the hardware smart
enough to realise that the keyswitch really shouldn't be turned
while 40 people are logged in? (Either way, I agree this'd be an
improvement. It'd sure make colocation a lot less painful.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
> > Now if these vendors could somehow eliminate downtime due to human error > > we'd be talking *serious* reliablity. > > You mean making the OS smart enough to know when clearing the arp > cache is a bonehead operation, or just making the hardware smart > enough to realise that the keyswitch really shouldn't be turned > while 40 people are logged in? (Either way, I agree this'd be an > improvement. It'd sure make colocation a lot less painful.) Well I was joking really, but those are two very good examples! Yes, machines should require extra confirmation for operationslike those. Hell, even a simple 'init 0' would be well served by a prompt that says "There are currently 400 network socketsopen, 50 remote users logged in, and 25 disk IOs per second. What's more, there's nobody logged in at the console to boot me up again afterwards - are you _sure_ you want to shut the machine down?". It's also crazy that there's no prompt after an 'rm -rf'(we could have 'rm -rf --iacceptfullresponsibility' for an unprompted version). Stuff like that would have saved me from a few embarrassments in the past for sure ;-) It drives me absolutely nuts every time I see a $staggeringly_expensive clustered server whose sysadmins are scared to doa failover test in case something goes wrong! Or which has worse uptime than my desktop PC because the cluster software's poorly setup or administered. Or which has both machines on the same circuit breaker. I could go on but it's depressing me. Favourite anecdote: A project manager friend of mine had a new 'lights out' datacenter to set up. The engineers, adminsand operators swore blind that everything had been tested in every possible way, and that incredible uptime was guaranteed. 'So if I just pull this disk out everything will keep working?' he asked, and then pulled the disk out without waiting for an answer... Ever since he told me that story I've done exactly that with every piece of so-called 'redundant' hardware a vendor triesto flog me. Ask them to set it up, then just do nasty things to it without asking for permission. Less than half the gear makesit through that filter, and actually you can almost tell from the look on the technical sales rep's face as you reach for the drive/cable/card/whatever whether it will or won't. M
>>>>> "SS" == Stalin Subbiah <Subbiah> writes: SS> We are looking into Sun V210 (2 x 1 GHz cpu, 2 gig ram, 5.8Os) SS> vs. Dell 1750 (2 x 2.4 GHz xeon, 2 gig ram, RH3.0). database will SS> mostly be write intensive and disks will be on raid 10. Wondering SS> if 64bit 1 GHz to 32bit 2.4 GHz make a big difference here. Spend all your money speeding up your disk system. If you're mostly writing (like my main app) then that's your bottleneck. I use a dell 2650 with external RAID 5 on 14 spindles. I didn't need that much disk space, but went for maxing out the number of spindles. RAID 5 was faster than RAID10 or RAID50 with this configuration for me. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D. Khera Communications, Inc. Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/