Re: hardware performance and some more

> Now, the second question is related to the performance of the database. Assuming we have a
> dell's poweredge 6650 with 4 x 2.8 Ghz Xeon processors having 2 MB of cache for each, with the
> main memory of lets say 32 GB. We can either use a small SAN from EMC or we can put all disks
> into the machines with the required raid confiuration.
>
> We will install RedHat Advanced Server 2.1 to the machine as the operating system and postgresql as
> the database server. We have a database having 25 millions records having the length of 250 bytes
> on average for each record. And there are 1000 operators accessing the database concurrently. The main
> operation on the database (about 95%) is select rather than insert, so do you have any idea about
> the performance of the system?

I have a very similar installation: Dell PE6600 with dual 2.0 Xeons/2MB cache, 4 GB memory, 6-disk RAID-10 for data, 2-disk RAID-1 for RH Linux 8. My database has over 60 million records averaging 200 bytes per tuple. I have a large nightly data load, then very complex multi-table join queries all day with a few INSERT transactions. While I do not have 1000 concurrent users (more like 30 for me), my processors and disks seem to be idle the vast majority of the time - this machine is overkill. So I think you will have no problem with your hardware, and could probably easily get away with only two processors. Someday, if you can determine with certainty that the CPU is a bottleneck, drop in the 3rd and 4th processors (and $10,000). And save yourself money on the RAM as well - it's incredibly easy to put in more if you need it. If you really want to spend money, set up the fastest disk arrays you can imagine.

I cannot emphasize enough: allocate a big chunk of time for tuning your database and learning from this list. I migrated from Microsoft SQL Server. Out of the box PostgreSQL was horrible for me, and even after significant tuning it crawled on certain queries (compared to MSSQL). The list helped me find a data type mismatch in a JOIN clause, and since then the performance of PostgreSQL has blown the doors off of MSSQL. Since I only gave myself a couple days to do tuning before the db had to go in production, I almost had to abandon PostgreSQL and revert to MS. My problems were solved in the nick of time, but I really wish I had made more time for tuning.

Running strong in production for 7 months now with PostgreSQL 7.3, and eagerly awaiting 7.4!

Roman Fail
POS Portal, Inc.