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-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 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 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.
>
>
>
>
>
>
> ---------------------------(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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
