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 ...
Re: refusing connections based on load ... |
Список | 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 по дате отправления: