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-diskRAID-1 for RH Linux 8.  My database has over 60 million records averaging  200 bytes per tuple.  I have a large
nightlydata load, then very complex multi-table join queries all day with a few INSERT transactions.  While I do not
have1000 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
withonly two processors.  Someday, if you can determine with certainty that the CPU is a bottleneck, drop in the 3rd
and4th processors (and $10,000).   And save yourself money on the RAM as well - it's incredibly easy to put in more if
youneed 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
migratedfrom Microsoft SQL Server.  Out of the box PostgreSQL was horrible for me, and even after significant tuning it
crawledon certain queries (compared to MSSQL).  The list helped me find a data type mismatch in a JOIN clause, and
sincethen the performance of PostgreSQL has blown the doors off of MSSQL.  Since I only gave myself a couple days to do
tuningbefore the db had to go in production, I almost had to abandon PostgreSQL and revert to MS.  My problems were
solvedin 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.