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 |
+-----------------------------------------------------------------+
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 |