Re: hardware performance and some more - Mailing list pgsql-performance

On 24 Jul 2003 18:44 EEST you wrote:

> > 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 have some time for the production, therefore, i can wait for the beta and production of version 7.4.
as i have seeen from your comments, you have 30 clients reaching to the database. assuming the maximum number
of search for each client is 5 then, search per second will be atmost 3. in my case, there will be around
100 search per second. so the main bothleneck comes from there.

and finally, the rate for the insert operation is about %0.1  (1 in every thousand). I've started to learn
about my limitations a few days ago, i would like to learn whether i can solve my problem with postgresql
or not.

> 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.
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match