Re: Hardware recommendations to scale to silly load

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: matt <matt(at)ymogen(dot)net>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hardware recommendations to scale to silly load
Date: 2003-08-28 15:33:15
Message-ID: Pine.LNX.4.33.0308280927170.4163-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On 27 Aug 2003, matt wrote:

> > You probably, more than anything, should look at some kind of
> > superfast, external storage array
>
> Yeah, I think that's going to be a given. Low end EMC FibreChannel
> boxes can do around 20,000 IOs/sec, which is probably close to good
> enough.
>
> You mentioned using multiple RAID controllers as a boost - presumably
> the trick here is to split the various elements (WAL, tables, indexes)
> across different controllers using symlinks or suchlike? Can I feasibly
> split the DB tables across 5 or more controllers?

I'm not sure I'd split the tables by hand right up front. Try getting as
many hard drives as you can afford hooked up at once, and then try
different ways of partitioning them. I'm guessing that making two fairly
good sized 1+0 sets, one for data and one for WAL might be the best
answer.

> > Actually, I've seen stuff like that going on Ebay pretty cheap lately. I
> > saw a 64 CPU E10k (366 MHz CPUs) with 64 gigs ram and 20 hard drives going
> > for $24,000 a month ago. Put Linux or BSD on it and Postgresql should
> > fly.
>
> Jeez, and I thought I was joking about the Starfire. Even Slowaris
> would be OK on one of them.
>
> The financial issue is that there's just not that much money in the
> micropayments game for bursty sales. If I was doing these loads
> *continuously* then I wouldn't be working, I'd be in the Maldives :-)

$24,000 isn't that much for a server really, and if you can leverage this
one "sale" to get more, then it would likely pay for itself over time.

If you have problems keeping up with load, it will be harder to get more
customers, so you kinda wanna do this as well as possible the first time.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2003-08-28 15:37:18 bug with constraint dependencies? or bug with pg_dump/pg_restore?
Previous Message Marie G. Tuite 2003-08-28 15:18:56 Re: before trigger problem

Browse pgsql-performance by date

  From Date Subject
Next Message Sean Chittenden 2003-08-28 16:12:33 Re: The results of my PostgreSQL/filesystem performance tests
Previous Message Stephan Szabo 2003-08-28 15:19:53 Re: Simple queries take forever to run