Re: hardware performance and some more

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: hardware performance and some more
Date: 2003-07-25 14:19:56
Message-ID: 1059142796.26034.106.camel@haggis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 2003-07-25 at 11:38, Kasim Oztoprak wrote:
> On 24 Jul 2003 23:25 EEST you wrote:
>
> > On Thu, 2003-07-24 at 13:25, Kasim Oztoprak wrote:
> > > On 24 Jul 2003 17:08 EEST you wrote:
> > >
> > > > On 24 Jul 2003 at 15:54, Kasim Oztoprak wrote:
> > [snip]
> > >
> > > we do not have memory problem or disk problems. as I have seen in the list the best way to
> > > use disks are using raid 10 for data and raid 1 for os. we can put as much memory as
> > > we require.
> > >
> > > now the question, if we have 100 searches per second and in each search if we need 30 sql
> > > instruction, what will be the performance of the system in the order of time. Let us say
> > > we have two machines described aove in a cluster.
> >
> > That's 3000 sql statements per second, 180 thousand per minute!!!!
> > What the heck is this database doing!!!!!
> >
> > A quad-CPU Opteron sure is looking useful right about now... Or
> > an quad-CPU AlphaServer ES45 running Linux, if 4x Opterons aren't
> > available.
> >
> > How complicated are each of these SELECT statements?
>
> this is kind of directory assistance application. actually the select statements are not
> very complex. the database contain 25 million subscriber records and the operators searches
> for the subscriber numbers or addresses. there are not much update operations actually the
> update ratio is approximately %0.1 .
>
> i will use at least 4 machines each having 4 cpu with the speed of 2.8 ghz xeon processors.
> and suitable memory capacity with it.
>
> i hope it will overcome with this problem. any similar implementation?

Since PG doesn't have active-active clustering, that's out, but since
the database will be very static, why not have, say 8 machines, each
with it's own copy of the database? (Since there are so few updates,
you feed the updates to a litle Perl app that then makes the changes
on each machine.) (A round-robin load balancer would do the trick
in utilizing them all.)

Also, with lots of machines, you could get away with less expensive
machines, say 2GHz CPU, 1GB RAM and a 40GB IDE drive. Then, if one
goes down for some reason, you've only lost a small portion of your
capacity, and replacing a part will be very inexpensive.

And if volume increases, just add more USD1000 machines...

--
+-----------------------------------------------------------------+
| Ron Johnson, Jr. Home: ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA |
| |
| "I'm not a vegetarian because I love animals, I'm a vegetarian |
| because I hate vegetables!" |
| unknown |
+-----------------------------------------------------------------+

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shridhar Daithankar 2003-07-25 15:31:44 Re: hardware performance and some more
Previous Message Shridhar Daithankar 2003-07-25 14:03:26 Re: hardware performance and some more