Re: hardware performance and some more

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: hardware performance and some more
Дата
Msg-id 1059142796.26034.106.camel@haggis
обсуждение исходный текст
Ответ на Re: hardware performance and some more  (Kasim Oztoprak <kasim@saglik.gov.tr>)
Ответы Re: hardware performance and some more
Список 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 по дате отправления:

Предыдущее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: hardware performance and some more
Следующее
От: Kasim Oztoprak
Дата:
Сообщение: Re: hardware performance and some more