Jason, 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