From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Sun performance - Major discovery! |
Date: | 2003-10-08 12:36:56 |
Message-ID: | Pine.BSF.4.44.0310080817500.62574-100000@torgo.978.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Well, as you guys know I've been tinkering with sun-vs-linux postgres for
a while trying to come up with reasons for the HUGE performance
differences. We've all had our anecdotal thoughts (fork sucks, ipc sucks,
ufs sucks, etc) and I've had a breakthrough.
Knowing that GCC only produces good code on x86 (and powerpc with apple's
mods, but it is doubtful that is as good as ibm's power compiler) I
decided to try out Sunsoft CC. I'd heard from more than one person/place
that gcc makes abysmal sparc code. Given that the performance profiles
for both the linux and sun boxes showed the same functions taking up most
of the time I thought I'd see what a difference sunsoft could give me.
So - hardware -
Sun E450 4x400mhz ultrasparc IIi, 4GB ram, scsi soemthing disk. (not
raid) solaris 2.6
Linux - 2xP3 500mhz, 2GB, scsi disk of some flavor (not raid) linux 2.2.17
(old I know!)
So here's the results using my load tester (single connection per beater,
repeats the query 1000 times with different input each time (we'll get
~20k rows back), the query is a common query around here.
I discounted the first run of the test as caches populated.
Linux - 1x - 35 seconds, 20x - 180 seconds
Sun - gcc - 1x 60 seconds 20x 245 seconds
Sun - sunsoft defaults - 1x 52 seonds 20x [similar to gcc most likely]
Sun - sunsoft -fast - 1x 28 seconds 20x 164 seconds
As you math guru's can probably deduce - that is a rather large
improvement. And by rather large I mean hugely significant. With results
like this, I think it warrants mentioning in the FAQ_Solaris, and probably
the performance guide.
Connecting will always be a bit slower. But I think most people realize
that connecting to a db is not cheap.
I think update/etc will cause more locking, but I think IO will become the
bottle neck much sooner than lock/unlock will. (This is mostly anecdotal
given how fast solaris can lock/unlock a semaphore and how much IO I know
I have)
Oh yes, with was with 7.3.4 and sunsoft cc Sun WorkShop 6 update 1 C
5.2 2000/09/11 (which is old, perhaps newer ones make even better code?)
I'm not sure of PG's policy of non-gcc things in configure, but perhaps if
we detect sunsoft we toss in the -fast flag and maybe make it the
preferred one on sun? [btw, it compiled with no changes but it did spew
out tons of warnings]
comments?
--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-10-08 12:59:20 | Re: new initdb.c available |
Previous Message | Zeugswetter Andreas SB SD | 2003-10-08 11:55:58 | Re: new initdb.c available |
From | Date | Subject | |
---|---|---|---|
Next Message | Andriy Tkachuk | 2003-10-08 13:16:52 | IMMUTABLE function's flag do not work: 7.3.4, plpgsql |
Previous Message | Tom Lane | 2003-10-08 04:15:57 | Re: TPC-R benchmarks |