Re: hardware performance and some more - Mailing list pgsql-performance
From | Ron Johnson |
---|---|
Subject | Re: hardware performance and some more |
Date | |
Msg-id | 1059142796.26034.106.camel@haggis Whole thread Raw |
In response to | Re: hardware performance and some more (Kasim Oztoprak <kasim@saglik.gov.tr>) |
Responses |
Re: hardware performance and some more
|
List | 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.l.johnson@cox.net | | Jefferson, LA USA | | | | "I'm not a vegetarian because I love animals, I'm a vegetarian | | because I hate vegetables!" | | unknown | +-----------------------------------------------------------------+
pgsql-performance by date: