Thread: Solaris Performance
We've been running equivalent configurations and schema on HP-UX, Solaris, and x86 Linux, and benchmarking with pgbench and some application-specific data. All testing was with 7.2rc2, and all were built natively on each platform. Performance on Solaris (2.6 and 2.7) seems lackluster, even when postgres processes are not CPU, memory, or IO bound, and whether over local Unix or tcpip sockets. Are there any other Solaris-specific optimizations or configuration items that we should consider? -- P. J. "Josh" Rovero Sonalysts, Inc. Email: rovero@sonalysts.com www.sonalysts.com 215 Parkway North Work: (860)326-3671 or 442-4355 Waterford CT 06385 ***********************************************************************
"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:
> We've been running equivalent configurations and schema on
> HP-UX, Solaris, and x86 Linux, and benchmarking with
> pgbench and some application-specific data. All testing
> was with 7.2rc2, and all were built natively on each platform.
> Performance on Solaris (2.6 and 2.7) seems lackluster,
Seeing as how those are three different hardware platforms, one must
wonder how sure you are that you are comparing apples to apples.
A difference in CPU speed or disk speed could explain everything.
regards, tom lane
P.J. "Josh" Rovero wrote: > We've been running equivalent configurations and schema on > HP-UX, Solaris, and x86 Linux, and benchmarking with > pgbench and some application-specific data. All testing > was with 7.2rc2, and all were built natively on each platform. > > Performance on Solaris (2.6 and 2.7) seems lackluster, even when > postgres processes are not CPU, memory, or IO bound, and whether > over local Unix or tcpip sockets. > > Are there any other Solaris-specific optimizations or configuration > items that we should consider? Yes, we have heard this report several times. We know process startup is slower on Solaris that other operating systems. How much of your testing is related to starting a new process? Other than that, we think perhaps the sheer weight of Solaris is slowing us down, though we don't have any hard answers to give you. Sorry. I would rather have given a better answer. We are willing to work with you to idenfity the parts that are slowest and see if we can somehow work around them. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane wrote: > "P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes: > > We've been running equivalent configurations and schema on > > HP-UX, Solaris, and x86 Linux, and benchmarking with > > pgbench and some application-specific data. All testing > > was with 7.2rc2, and all were built natively on each platform. > > > Performance on Solaris (2.6 and 2.7) seems lackluster, > > Seeing as how those are three different hardware platforms, one must > wonder how sure you are that you are comparing apples to apples. > A difference in CPU speed or disk speed could explain everything. Agreed, but if I had to take a guess, my bet is he is going to say the Solaris box is faster in all ways. We have heard such reports before. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
For non-postgresql applications, the Suns are typically faster than the HPs. While direct comparisons are always dangerous, the SPARC chips are clocked at about 2-3 times what the PA-RISC chips are. The postgresql performance on Solaris is an order of magnitude (10x) slower than Linux x86 at same CPU clock speed. Tom Lane wrote: > "P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes: > >>We've been running equivalent configurations and schema on >>HP-UX, Solaris, and x86 Linux, and benchmarking with >>pgbench and some application-specific data. All testing >>was with 7.2rc2, and all were built natively on each platform. >> > >>Performance on Solaris (2.6 and 2.7) seems lackluster, >> > > Seeing as how those are three different hardware platforms, one must > wonder how sure you are that you are comparing apples to apples. > A difference in CPU speed or disk speed could explain everything. > > regards, tom lane > > > -- P. J. "Josh" Rovero Sonalysts, Inc. Email: rovero@sonalysts.com www.sonalysts.com 215 Parkway North Work: (860)326-3671 or 442-4355 Waterford CT 06385 ***********************************************************************
"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:
> For non-postgresql applications, the Suns are
> typically faster than the HPs. While direct
> comparisons are always dangerous, the SPARC
> chips are clocked at about 2-3 times what
> the PA-RISC chips are.
> The postgresql performance on Solaris is
> an order of magnitude (10x) slower than
> Linux x86 at same CPU clock speed.
Hmm. So can you figure out where the time is going? What do you see
with top, iostat, vmstat, ...? Can you recompile with profiling (gmake
clean, gmake PROFILE=-pg all typically works on gcc platforms) and learn
something about where the backend is spending its time?
regards, tom lane
P.J. "Josh" Rovero wrote: > For non-postgresql applications, the Suns are > typically faster than the HPs. While direct > comparisons are always dangerous, the SPARC > chips are clocked at about 2-3 times what > the PA-RISC chips are. > > The postgresql performance on Solaris is > an order of magnitude (10x) slower than > Linux x86 at same CPU clock speed. Wow, that is dramatic. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Actually, the first question to ask might be "are you using gcc"?
It looks to me like s_lock.h/s_lock.c don't have a non-gcc
implementation of tas() unless you define NEED_SPARC_TAS_ASM
... which src/include/port/solaris.h doesn't. Ugh.
regards, tom lane
Tom Lane wrote: > Actually, the first question to ask might be "are you using gcc"? > > It looks to me like s_lock.h/s_lock.c don't have a non-gcc > implementation of tas() unless you define NEED_SPARC_TAS_ASM > ... which src/include/port/solaris.h doesn't. Ugh. Ouch. Can we throw a message in the server logs when we are using the non-asm locking code? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>scratches head ... ] I didn't think there was anything particularly >system-dependent about the sorting code. Have you tried profiling, or >anything to determine where the Solaris version is spending its time? No... Have not tried these queries again - had some grumpy developers monstering me about the machine responsiveness...( err what is that postgres process with 100% of 1 cpu doing ? etc) I will try profiling the query when they forgive me regards Mark
Just had a thought, It would be interesting to know how PostgreSQL performs on Linux on SPARC, compared to how it performs on Solaris on SPARC. Assuming PostgreSQL runs on Linux on SPARC (can't remember). Has anyone ever done decent testing of this? :-) Regards and best wishes, Justin Clift Mark kirkwood wrote: > > >scratches head ... ] I didn't think there was anything particularly > >system-dependent about the sorting code. Have you tried profiling, or > >anything to determine where the Solaris version is spending its time? > > No... Have not tried these queries again - had some grumpy developers > monstering me about the machine responsiveness...( err what is that > postgres process with 100% of 1 cpu doing ? etc) > > I will try profiling the query when they forgive me > > regards > > Mark > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Sun, Feb 10, 2002 at 06:31:13PM +1100, Justin Clift wrote: > Just had a thought, > > It would be interesting to know how PostgreSQL performs on Linux on > SPARC, compared to how it performs on Solaris on SPARC. > > Assuming PostgreSQL runs on Linux on SPARC (can't remember). It does. Debian has successfully built 7.1.3 on basically every architecture supported, which include SPARC. Unfortunatly they don't run the regression tests so it's not clear if all the compiler warnings are meaningless. http://buildd.debian.org/build.php?arch=&pkg=postgresql > Has anyone ever done decent testing of this? I just got a SPARC box but it's not configured in any way. If I ever get it working, I'll try it out. Anybody else? -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Terrorists can only take my life. Only my government can take my freedom.
Martijn van Oosterhout <kleptog@svana.org> writes: >> Assuming PostgreSQL runs on Linux on SPARC (can't remember). > It does. Debian has successfully built 7.1.3 on basically every architecture > supported, which include SPARC. Unfortunatly they don't run the regression > tests so it's not clear if all the compiler warnings are meaningless. > http://buildd.debian.org/build.php?arch=&pkg=postgresql Those warnings look like the same ones I've seen many times on Debian Alpha. AFAICT they're indicative of nothing except sloppy programming in a system header file. I can report that 7.2 passes regression tests on sourceforge's SPARC/Linux machine, which claims to be Debian 2.2. uname says Linux usf-cf-sparc-linux-1 2.2.18pre21 #1 SMP Wed Nov 22 17:27:17 EST 2000 sparc64 unknown Curiously, though, I don't see any of the mathinline warnings on that machine. Slightly different Debian version perhaps? regards, tom lane
Awhile back I said:
> Actually, the first question to ask might be "are you using gcc"?
> It looks to me like s_lock.h/s_lock.c don't have a non-gcc
> implementation of tas() unless you define NEED_SPARC_TAS_ASM
> ... which src/include/port/solaris.h doesn't. Ugh.
I have to take this back: for non-gcc on Sparc, we use out-of-line
TAS subroutines, see src/backend/port/tas/. So that's not the problem.
regards, tom lane
I'm running PostgreSQL on a Sun Ultra 60 running Solaris 8. It's maybe not a fair comparison, as before I was running everything (JBoss/TomCat/Apache/PostgreSQL) on a 550MHz Pentium with 384M of RAM, and a single 7200 RPM IDE drive, but I got a real big boost in performance when I moved PosgreSQL onto the Solaris box. It seems like a pretty good platform for PosgreSQL, and I would think the 10K drives would speed things up a bit. But I'm no expert. Kelly McTiernan "Scott Marlowe" <smarlowe@ihs.com> wrote in message news:a03059a3.0202130819.465f316a@posting.google.com... > justin@postgresql.org (Justin Clift) wrote in message news:<3C6621C1.85C8479D@postgresql.org>... > > Just had a thought, > > > > It would be interesting to know how PostgreSQL performs on Linux on > > SPARC, compared to how it performs on Solaris on SPARC. > > > > Assuming PostgreSQL runs on Linux on SPARC (can't remember). > > > > Has anyone ever done decent testing of this? > > A buddy of mine at work and I did. I put my Sparc20 with 512 Meg RAM > against his Ultra 1 with 256 megs of RAM. I was running a single 2 > Gig Barracuda drive with narrow SCSI and he was running a 5 to 10 Gig > ide drive. My Sparc 20 was running RedHat 6.2 and his was running the > latest and greatest version of Solaris at the time last fall. Both > machines had compiled postgresql 7.1.2 or 7.1.3, whichever was out > then with gcc. > > My Sparc 20 was a match for the Ultra 1 for every query we threw at > them. Sometimes a little slower, mostly a little faster. > > I'd like to get the time to put Linux and Solaris dual boot on an > Ultra 60 or something and get some real numbers, but our little test > convinced me that Linux is a much better platform for Postgresql than > Solaris. > > I've heard similar stories re: BSD performance being much worse than > Linux for postgresql but haven't had any chance to do any testing. > > My thanks to all the postgresql developers, we love you man! :-) > > Scott Marlowe