Re: Peformance Tuning Opterons/ Hard Disk Layout

Поиск
Список
Период
Сортировка
От John Allgood
Тема Re: Peformance Tuning Opterons/ Hard Disk Layout
Дата
Msg-id 421CD668.7010503@turbocorp.com
обсуждение исходный текст
Ответ на Re: Peformance Tuning Opterons/ Hard Disk Layout  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Peformance Tuning Opterons/ Hard Disk Layout  (John Arbash Meinel <john@arbash-meinel.com>)
Re: Peformance Tuning Opterons/ Hard Disk Layout  (Michael Adler <adler@pobox.com>)
Список pgsql-performance
I think maybe I didn't explain myself well enough. At most we will
service 200-250 connections across all the 9 databases mentioned. The
database we are building is for a trucking company. Each of the
databases represents a different division. With one master database that
everything is updated to. Most of the access to the database is by
simple queries. Most of the IO intensive stuff is done when revenue
reports are generated and when we have our month/year end processing.
All the trucking loads that are mark as delivered are transferred to our
master database during night time processing. All that will be handled
using custom scripts. Maybe I have given a better explanation of the
application. my biggest concern is how to partition the shared storage
for maximum performance. Is there a real benifit to having more that one
raid5 partition or am I wasting my time.

Thanks

John Allgood - ESC


Tom Lane wrote:
>"Bruno Almeida do Lago" <teolupus@gmail.com> writes:
>
>>Is there a real limit for max_connections? Here we've an Oracle server with
>>up to 1200 simultaneous conections over it!
>>
>
>[ shrug... ] If your machine has the beef to run 1200 simultaneous
>queries, you can set max_connections to 1200.
>
>The point of what you were quoting is that if you want to service
>1200 concurrent users but you only expect maybe 100 simultaneously
>active queries from them (and you have a database box that can only
>service that many) then you want to put a connection pooler in
>front of 100 backends, not try to start a backend for every user.
>
>Oracle may handle this sort of thing differently, I dunno.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org
>
>

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Peformance Tuning Opterons/ Hard Disk Layout
Следующее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: is pg_autovacuum so effective ?