Your question is really suited to the PERFORMANCE list, not NOVICE, so I have 
cross-posted it there.  I reccomend that you subscribe to performance, and 
drop novice from your replies.   There are lots of hardware geeks on 
performance, but few on novice.

> We have an opportunity to purchase a new, top-notch database server. I am
> wondering what kind of hardware is recommended? We're on Linux platforms
> and kernels though. I remember a comment from Tom about how he was spending
> a lot of time debugging problems which turned out to be hardware-related. I
> of course would like to avoid that.
> In terms of numbers, we expect have an average of 100 active connections
> (most of which are idle 9/10ths of the time), with about 85% reading
> traffic. I expect the database with flow average 10-20kBps under moderate
> load. I hope to have one server host about 1000-2000 active databases, with
> the largest being about 60 meg (no blobs). Inactive databases will only be
> for reading (archival) purposes, and will seldom be accessed.

Is that 100 concurrent connections *total*, or per-database?   If the 
connections are idle 90% of the time, then are they open, or do they get 
re-established with each query?  Have you considered connection pooling for 
the read-only queries?

> Does any of this represent a problem for Postgres? The datasets are
> typically not that large, only a few queries on a few databases ever return
> over 1000 rows. I'm worried about being able to handle the times when there
> will be spikes in the traffic.

It's all possible, it just requires careful application design and lots of 
hardware.   You should also cost things out; sometimes it's cheaper to have 
several good servers instead of one uber-server.   The latter also helps with 
hardware replacement.

> The configuration that is going on in my head is:
> RAID 1, 200gig

RAID 1+0 can be good for Postgres.   However, if you have a budget, RAID 5 
with 6 or more disks can be better some of the time, particularly when read 
queries are the vast majority of the load.  There are, as yet, no difinitive 
statistics, but OSDL is working on it!

More important than the RAID config is the RAID card; once again, with money, 
multi-channel RAID cards with a battery-backed write cache are your best bet; 
some cards even allow you to span RAID1 between cards of the same model.  See 
the discussion about LSI MegaRaid in the PERFORMANCE list archives over the 
last 2 weeks.

> 1 server, 4g ram
> Linux 2.6

You're very brave.  Me, I'm not adopting 2.6 in production until 2.6.03 is 
out, at least.

> I was also wondering about storage units (IBM FAStT200) with giga-bit
> Ethernet to rack mount computer(s)... But would I need more than 1 CPU? If
> I did, how would I handle the file system? We only do a few joins, so I
> think most of it would be I/O latency.

PostgreSQL will make use of multiple processors.   If you are worried about 
peak time loads, having 2-4 processors to distribute queries across would be 
very useful.

Also, I'm concerned about the "we only do a few joins".    What that says to 
me is "we don't really know how to write complex queries, so we pull a lot of 
redundant data."   Simple queries can be far less efficient than complex ones 
if they result in you pulling entire tables across to the client.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to