Re: Re: Re: refusing connections based on load ...

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: Re: Re: refusing connections based on load ...
Дата
Msg-id Pine.BSF.4.33.0104242326210.4451-100000@mobile.hub.org
обсуждение исходный текст
Ответ на Re: Re: refusing connections based on load ...  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Ответы Re: Re: Re: refusing connections based on load ...  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Re: refusing connections based on load ...  (ncm@zembu.com (Nathan Myers))
Список pgsql-hackers
On Wed, 25 Apr 2001, Lincoln Yeoh wrote:

> At 10:59 PM 23-04-2001 -0700, Nathan Myers wrote:
> >On Tue, Apr 24, 2001 at 12:39:29PM +0800, Lincoln Yeoh wrote:
> >> Why not be more deterministic about refusing connections and stick
> >> to reducing max clients? If not it seems like a case where you're
> >> promised something but when you need it, you can't have it.
> >
> >The point is that "number of connections" is a very poor estimate of
> >system load.  Sometimes a connection is busy, sometimes it's not.
>
> Actually I use number of connections to estimate how much RAM I will need,
> not for estimating system load.
>
> Because once the system runs out of RAM, performance drops a lot. If I can
> prevent the system running out of RAM, it can usually take whatever I throw
> at it at near the max throughput.

I have a Dual-866, 1gig of RAM and strip'd file systems ... this past
week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and
disks are pretty much sitting idle ...

It turns out, in this case, that vacuum was in order (i vacuum 12x per day
now instead of 6), so that now it will run with 300 simultaneous
connections, but with a loadavg of 68 or so, 300 connections are just
building on each other to slow the rest down :(




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

Предыдущее
От: Lincoln Yeoh
Дата:
Сообщение: Re: Re: refusing connections based on load ...
Следующее
От: Philip Warner
Дата:
Сообщение: Re: pg_dump