Обсуждение: advice on buying sun hardware to run postgres
I am going to buying a sun server to run postgres
on as a backend database server for a www site. Does anyone
have suggestions on what to buy? Does anyone have
advice on running postgres on solaris or suggestions not to?
My budget is 5k to 10k but i'm looking for a machine that
can scale cpus and memory.
The sun enterprise 5 looks nice but absurdly comes
with ide discs and doesn't seem to scale cpus. Seems i
have to go with an enterprise 250 in order to get multiple
cpus. enterprise 250 is in my budget of 10k but you certainly
don't have to pay that much for multiple cpus on intel machines.
Does anyone think i could get just as much running postgres
on a dual pent III with linux or FreeBSD as i could on a sun enterprise
250?
> I am going to buying a sun server to run postgres > on as a backend database server for a www site. Does anyone > have suggestions on what to buy? Does anyone have > advice on running postgres on solaris or suggestions not to? > My budget is 5k to 10k but i'm looking for a machine that > can scale cpus and memory. IDE is just plain slow on Unix. Unix does much better with SCSI, especially when there are multiple disks. > The sun enterprise 5 looks nice but absurdly comes > with ide discs and doesn't seem to scale cpus. Seems i > have to go with an enterprise 250 in order to get multiple > cpus. enterprise 250 is in my budget of 10k but you certainly > don't have to pay that much for multiple cpus on intel machines. > > Does anyone think i could get just as much running postgres > on a dual pent III with linux or FreeBSD as i could on a sun enterprise > 250? Good question. I know BSDI runs well on two cpu's, and I know FreeBSD and Linux use them too. On intel platforms, you are not going to find many OS's that can handle _more_ than two cpu's, so the Sun may make sense if you think you are going to need more than two cpus. I know someone recently posted a comparison of Solaris and Linux, and Solaris was half the speed, but I don't remember what versions/hardware was involved. You can check the mailing list archives. We have continued to speed up PostgreSQL to the point where many operations are running at the native speed of the disk drive, so you may find that the limiting factor is how fast data can be taken from the disk. Perhaps I should have an FAQ for this, but I am not sure how to address it because the answers people want are not usually the same. -- Bruce Momjian | http://www.op.net/~candle maillist@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
On Sun, 25 Apr 1999, Bruce Momjian wrote:
// IDE is just plain slow on Unix. Unix does much better with SCSI,
// especially when there are multiple disks.
Although it's not as obvious to most home users, UNIX does much
better on RISC processors, too. Although a CISC processor can often
execute a single process faster, once you get into having to try to do
multiprocessing, the RISC is a big win. Anyone who's ever run a machine
up to a load of around 100-150 knows all about this. :)
If you're not willing to spend money on Sun hardware, though, it's
hard to see a gain. With similarly priced hardware, the PC will often be
faster, but you can make some nice high-end server. I'm running a
postgres server at work on a 2 processor Ultra 2 with a gig or so of RAM.
My actual database servers at work have at least 4 Ultra processors with
4GB of RAM, but they (most of them) will hold up to 14 processors and 14GB
of RAM.
--
Principal Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __
Bruce Momjian wrote: > > > I am going to buying a sun server to run postgres > > on as a backend database server for a www site. Does anyone > > have suggestions on what to buy? Does anyone have > > advice on running postgres on solaris or suggestions not to? > > My budget is 5k to 10k but i'm looking for a machine that > > can scale cpus and memory. > > IDE is just plain slow on Unix. Unix does much better with SCSI, > especially when there are multiple disks. Oh I don't know. If you've only got 1 or 2 disks you may find IDE sufficient. (well it works nicely for me.) > > Does anyone think i could get just as much running postgres > > on a dual pent III with linux or FreeBSD as i could on a sun > > enterprise 250? People have been commenting lately that postgres on Solaris is very slow compared to Linux. Apparently certain file system operations on Solaris is _slow_. > Good question. I know BSDI runs well on two cpu's, and I know FreeBSD > and Linux use them too. On intel platforms, you are not going to find > many OS's that can handle _more_ than two cpu's, I disagree. I think Linux 2.2 should be able to go to 4 CPUs no problem. Linus's personal machine has 4. I heard that FreeBSD's SMP isn't very advanced but I have no personal experience.
On Sun, 25 Apr 1999, Eric Enockson wrote: > I am going to buying a sun server to run postgres > on as a backend database server for a www site. Does anyone > have suggestions on what to buy? Does anyone have > advice on running postgres on solaris or suggestions not to? Several posters have noted a particular slowness of solaris running on SPARC architecture w/respect to postgres. But there are a lot of details which are not known with respect to the observed slowness (could be OS, could be disk drives, could be CPUs, could be cache etc...). regarding IDE drives. an employee of mine has been talking about some cheap high speed I/O storage solutions which are IDE based. 17G hard drives running at only 5400rpm which outperform 10K rpm SCSI drives because their areal density is so much higher. and they only cost $350 a piece. however, the one drawback is that IDE is not well suited to RAIDs. so what's your app. if you aren't RAIDing, why not go with high areal density IDEs? > cpus. enterprise 250 is in my budget of 10k but you certainly > don't have to pay that much for multiple cpus on intel machines. multiple CPUs are certainly way cheaper if you go the x86 route. > > Does anyone think i could get just as much running postgres > on a dual pent III with linux or FreeBSD as i could on a sun enterprise > 250? likely. i am disappointed with general application performance on a SPARCstation 10 (albeit much older box than E250). I love the stability of the OS and its scalability with respect to networking functions. It handles lots of users very well and serves the applications to those users very well. It runs sendmail, apache and other network services without ever so much as hiccuping. but SAS, postgres and netscape run like snails on it. just my $0.02. steve
On Mon, 26 Apr 1999, Chris Bitmead wrote:
# > IDE is just plain slow on Unix. Unix does much better with SCSI,
# > especially when there are multiple disks.
#
# Oh I don't know. If you've only got 1 or 2 disks you may find IDE
# sufficient. (well it works nicely for me.)
Works != works as well as SCSI. I've yet to find an example where
IDE works as well as SCSI in real life (vs. benchmarks). My real life
scenarios rarely involve telling a machine to be still so we can do a disk
read, then again for a disk write.
# People have been commenting lately that postgres on Solaris is very slow
# compared to Linux. Apparently certain file system operations on Solaris
# is _slow_.
Slow, however more robust than the same in Linux. Linux achieves
a lot of speed by throwing away safety nets. Sometimes, these safety nets
are important.
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
> Works != works as well as SCSI. I've yet to find an example where > IDE works as well as SCSI in real life (vs. benchmarks). My real life > scenarios rarely involve telling a machine to be still so we can do a disk > read, then again for a disk write. Probably true. IDE can not access more than one drive at a time, and requires CPU to complete the data transfers. > > # People have been commenting lately that postgres on Solaris is very slow > # compared to Linux. Apparently certain file system operations on Solaris > # is _slow_. > > Slow, however more robust than the same in Linux. Linux achieves > a lot of speed by throwing away safety nets. Sometimes, these safety nets > are important. Yes, it is hard to write code that is fast for small cases, but scales well for large cases. It can be done, it is just not easy. -- Bruce Momjian | http://www.op.net/~candle maillist@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
Hi Postgreser's
A DEC (sorry Compaq) Alpha running Linux is a mean combination. Used
Alpha's can be had fairly cheap and they really scream. If cost is an
issue, I would look for an older one used e.g. a
DEC 2100/A500MP (was marketed as a "Sable")
Put Linux on the beast and watch the smoke roll.
Just my .02
Regards,
Jim
At 22:00 4/25/99 -0700, you wrote:
>On Sun, 25 Apr 1999, Bruce Momjian wrote:
>
>// IDE is just plain slow on Unix. Unix does much better with SCSI,
>// especially when there are multiple disks.
>
> Although it's not as obvious to most home users, UNIX does much
>better on RISC processors, too. Although a CISC processor can often
>execute a single process faster, once you get into having to try to do
>multiprocessing, the RISC is a big win. Anyone who's ever run a machine
>up to a load of around 100-150 knows all about this. :)
>
> If you're not willing to spend money on Sun hardware, though, it's
>hard to see a gain. With similarly priced hardware, the PC will often be
>faster, but you can make some nice high-end server. I'm running a
>postgres server at work on a 2 processor Ultra 2 with a gig or so of RAM.
>My actual database servers at work have at least 4 Ultra processors with
>4GB of RAM, but they (most of them) will hold up to 14 processors and 14GB
>of RAM.
>
>--
>Principal Member Technical Staff, beyond.com The world is watching
America,
>pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
>| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
>L______________________________________________ and America is watching
TV. __
>
>
>
,-,-. ,-,-. ,-,-. ,-,-. ,-
/ / \ \ / / \ \ / / \ \ / / \ \ / /
\ \ / / \ \ / / \ \ / / \ \ / /
`-'-' `-'-' `-'-' `-'-'
--------------------------------------------------------
FSC - Building Better Information Technology Solutions-
From the Production Floor to the Customer's Door.
--------------------------------------------------------
Jim Jennis, Technical Director, Commercial Systems
Fuentez Systems Concepts, Inc.
1 Discovery Place, Suite 2
Martinsburg, WV. 25401 USA.
Phone: +001 (304) 263-0163 ext 235
FAX: +001 (304) 263-0702
Email: jjennis@fuentez.com
jhjennis@shentel.net
---------------------------------------------------
Jim Jennis wrote: > A DEC (sorry Compaq) Alpha running Linux is a mean combination. Used > Alpha's can be had fairly cheap and they really scream. If cost is an > issue, I would look for an older one used e.g. a > > DEC 2100/A500MP (was marketed as a "Sable") > > Put Linux on the beast and watch the smoke roll. > Yep, and they do multiple processors (on linux as well, I couldn't find a link now, but I seem to remember a report of linux running on an 8-processor Alpha 8400. www.alphalinux.org is the place to look). We use Alpha with Digital Unix, because we do lots of number crunching (we need their compilers), and it's fast and rock-solid. And the new DS-20's have got a 5.2GB/s back-plane.... Intel eat your heart out..... The Alphas won't necessarily blow your mind on integer applications though, but they will hold their own. We switched from Sun a long time ago, and never looked back. Adriaan
Dustin Sallings wrote: > Works != works as well as SCSI. I've yet to find an example where > IDE works as well as SCSI in real life (vs. benchmarks). My real life > scenarios rarely involve telling a machine to be still so we can do a disk > read, then again for a disk write. Modern operating systems don't ask the disk to do something and then just wait for the answer. That's what interrupts are for. Anyway, modern disks have caches. >Slow, however more robust than the same in Linux. >Linux achieves > a lot of speed by throwing away safety nets. Sometimes, these > safety nets are important. Never lost a file to Linux in 5 years. -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com
> > Never lost a file to Linux in 5 years. Haha, just lost my home directory this weekend. But then again, I was in win98 when my rabbit chewed through a 220V cable and the whole room went black. Might just have something to do with it (but on the other hand, win98 shouldn't even be touching that disk, there's only linux partitions on it). Maarten -- Maarten Boekhold, boekhold@tibco.com TIBCO Finance Technology Inc. The Atrium Strawinskylaan 3051 1077 ZX Amsterdam, The Netherlands tel: +31 20 3012158, fax: +31 20 3012358 http://www.tibco.com
Maarten Boekhold wrote: > > Never lost a file to Linux in 5 years. > > Haha, just lost my home directory this weekend. But then again, I was in > win98 when my rabbit chewed through a 220V cable and the whole room went > black. Might just have something to do with it (but on the other hand, > win98 shouldn't even be touching that disk, there's only linux > partitions on it). You think you're hard done by. Think about the rabbit! -- Chris Bitmead http://www.bigfoot.com/~chris.bitmead mailto:chris.bitmead@bigfoot.com
On Tue, 27 Apr 1999, Chris Bitmead wrote:
# Modern operating systems don't ask the disk to do something and then
# just wait for the answer. That's what interrupts are for. Anyway, modern
# disks have caches.
You can only cache so much. At some point, you're going to
actually want to write something to a disk, and while you're doing this,
nothing else can read. This is why your system slows down sometimes even
when there's not a lot of intensive processing. This doesn't happen with
SCSI until you saturate your SCSI bandwidth.
Even disregarding theory, in practice, SCSI is always faster when
you're not doing single process per controller type access. If you're
running a database and concerned about performance, you use SCSI disks.
If your processor(s) has something better to do than disk I/O, then you
use SCSI.
# Never lost a file to Linux in 5 years.
I'm just glad I keep backups. When I was using Linux, I didn't
keep enough, though. I lost some really good stuff. I'd have a hard time
believing you've never lost a file unless the statement is qualified by
describing your backup strategy. It's very difficult to improperly shut
down a Linux machine while it's actually doing something and not lose a
file. It's very difficult to run an OS for five years without having it
improperly shut down (given normal home conditions).
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
Dustin Sallings wrote: > You can only cache so much. At some point, you're going to > actually want to write something to a disk, and while you're doing this, > nothing else can read. This is why your system slows down sometimes even > when there's not a lot of intensive processing. This doesn't happen with > SCSI until you saturate your SCSI bandwidth. Umm. SCSI or no SCSI, if the disk's cache is full and it has to go away and write stuff, then nobody is going to be able to read anything while this is happening. SCSI disks can't defy the laws of physics. So the OS is going to have to go and do something else in the meantime either way, no? > # Never lost a file to Linux in 5 years. > > I'm just glad I keep backups. When I was using Linux, I didn't > keep enough, though. I lost some really good stuff. I'd have a hard time > believing you've never lost a file unless the statement is qualified by > describing your backup strategy. It's very difficult to improperly shut > down a Linux machine while it's actually doing something and not lose a > file. It's very difficult to run an OS for five years without having it > improperly shut down (given normal home conditions). I've had the machine improperly shut down many many times for a variety of reasons. I've never restored a file from backup and I've never lost a file that I'm aware of. At least not that I can remember, if I did it couldn't have been very important because I didn't notice.
On Wed, 28 Apr 1999, Chris Bitmead wrote:
// Umm. SCSI or no SCSI, if the disk's cache is full and it has to go
// away and write stuff, then nobody is going to be able to read
// anything while this is happening. SCSI disks can't defy the laws of
// physics. So the OS is going to have to go and do something else in
// the meantime either way, no?
Short answer: You are incorrect.
Long answer: If you don't believe what people with experience with
these things are saying, do your own experimentation. For best results,
you can find some disks that are exactly the same internally but only vary
with their interfaces. Try different things that might happen in the real
world. I'd suggest starting by getting two machines, four disks, and one
IDE controller, and one SCSI controller. Build one machine on IDE and one
on SCSI. Do stuff like copying data from one disk to the other, install a
database server (i.e. postgres) and do some benchmarks. Do it again while
there's some activity on the other disk (i.e. build postgres) and see how
it does. In fact, just run a make on each disk and see which system
finishes first.
// I've had the machine improperly shut down many many times for a
// variety of reasons. I've never restored a file from backup and I've
// never lost a file that I'm aware of. At least not that I can
// remember, if I did it couldn't have been very important because I
// didn't notice.
*shrug* that's rare, then.
--
Principal Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __
dustin sallings wrote: > Short answer: You are incorrect. > > Long answer: If you don't believe what people with experience with > these things are saying, do your own experimentation. It's not a matter of not believing, it's of who to believe. Opinion seems divided 50/50. > For best results, > you can find some disks that are exactly the same internally but only vary > with their interfaces. Have you done such tests? If so, what exactly were the results? > Try different things that might happen in the real > world. I'd suggest starting by getting two machines, four disks, and one > IDE controller, and one SCSI controller. Build one machine on IDE and one > on SCSI. Do stuff like copying data from one disk to the other, install a > database server (i.e. postgres) and do some benchmarks. Do it again while > there's some activity on the other disk (i.e. build postgres) and see how > it does. In fact, just run a make on each disk and see which system > finishes first. > > // I've had the machine improperly shut down many many times for a > // variety of reasons. I've never restored a file from backup and I've > // never lost a file that I'm aware of. At least not that I can > // remember, if I did it couldn't have been very important because I > // didn't notice. > > *shrug* that's rare, then. > > -- > Principal Member Technical Staff, beyond.com The world is watching America, > pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net> > | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE > L______________________________________________ and America is watching TV. __
On Wed, 28 Apr 1999, Chris Bitmead wrote:
// It's not a matter of not believing, it's of who to believe. Opinion
// seems divided 50/50.
I'm not sure where you get 50/50. I've not met anyone who
recommended IDE disks over SCSI disks unless the only factor was price,
since IDE disks are generally available for less than SCSI disks. You
will get better performance with SCSI disks. That's just the way it is.
If you can provide any evidence to the contrary, I'll show you a
single-tasking operating system running a single process doing nothing but
sequential disk reads or write, hardly useful to anybody needing to store
or read data.
// > For best results,
// > you can find some disks that are exactly the same internally but only vary
// > with their interfaces.
//
// Have you done such tests? If so, what exactly were the results?
I don't need to. I've used both in real world environments. I
know just enough about the hardware to explain why IDE has always been
slower than SCSI in my environments. I *do* know that I've run out of
disk and have been able to slap an external disk on a running Sun and move
stuff over to it at home, and we've done similar things at work.
--
Principal Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __
dustin sallings wrote: > I'm not sure where you get 50/50. I've not met anyone who > recommended IDE disks over SCSI disks unless the only factor was price, No, I'm saying that if you've only got 1 or 2 disks, opinion seems divided over whether the difference in performance is enough to be concerned about. > // Have you done such tests? If so, what exactly were the results? > > I don't need to. I've used both in real world environments. I > know just enough about the hardware to explain why IDE has always been > slower than SCSI in my environments. Doesn't sound very scientific to me.
It appears to the untrained eye, that you guys may be comparing apples to oranges and therefore are both correct, in a way. It seems like most of Chris's usage of disks comes in a desktop environment while most of the Dustin's usage comes from the heavily loaded servers. In a desktop environment where the biggest bottleneck is a human operator and the disks most of the time sit around waiting for something to do Chris is correct in saying that the performance difference between IDE and SCSI is not that enormous. It is there, it simply may not be worth the extra trouble and expense. However, when you start, talking about a medium to heavy loaded server then the SCSI reliability, expandability and speed are a real advantage. In fact I would be willing to go so far as to say SCSI is the only way to go if you are planning to build a medium to heavy loaded server. I also hope this answers the question of the original poster, which sort of got lost here somewhere. :-) Rudy On 28 Apr 99, at 2:43, Chris Bitmead wrote: > dustin sallings wrote: > > > I'm not sure where you get 50/50. I've not met anyone who > > recommended IDE disks over SCSI disks unless the only factor was price, > > No, I'm saying that if you've only got 1 or 2 disks, opinion seems > divided over whether the difference in performance is enough to be > concerned about. > > > // Have you done such tests? If so, what exactly were the results? > > > > I don't need to. I've used both in real world environments. I > > know just enough about the hardware to explain why IDE has always been > > slower than SCSI in my environments. > > Doesn't sound very scientific to me. > >
On Wed, Apr 28, 1999 at 02:03:10AM +0000, Chris Bitmead wrote:
> > on SCSI. Do stuff like copying data from one disk to the other, install a
> > database server (i.e. postgres) and do some benchmarks. Do it again while
Where can I find some raliable SQL benchmarks? I want to test
general performance of different RDBMS.
Best regards,
--- Artur Pietruk, arturp@pdi.net