Re: Proposal of tunable fix for scalability of 8.4

Поиск
Список
Период
Сортировка
От Jignesh K. Shah
Тема Re: Proposal of tunable fix for scalability of 8.4
Дата
Msg-id 49BEAAE8.4010402@sun.com
обсуждение исходный текст
Ответ на Re: Proposal of tunable fix for scalability of 8.4  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-performance


On 03/16/09 11:08, Gregory Stark wrote:
"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
 
Generally when there is dead constant.. signs of classic bottleneck ;-)  We
will be fixing one to get to another.. but knocking bottlenecks is the name of
the game I think   
Indeed. I think the bottleneck we're interested in addressing here is why you
say you weren't able to saturate the 64 threads with 64 processes when they're
all RAM-resident.

From what I see you still have 400+ processes? Is that right?
 

Any one claiming they run CPU intensive are not always telling the truth.. They *Think* they are running CPU intensive for the right part but there could be memory misses, they could be doing statistics where they are not really stressing the intended stuff to test, they could be parsing through the results where they are not stressing the backend while still claiming to be cpu intensive (though from a different perspective)

So yes a single process  specially a client cannot claim to keep the backend 100% active but so can neither a connection pooler since it still has to some other stuff within the process.

-Jignesh

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: [ADMIN] deployment query
Следующее
От: Alan Hodgson
Дата:
Сообщение: Re: High CPU Utilization