Re: Re: Re: refusing connections based on load ... - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Re: Re: refusing connections based on load ...
Date
Msg-id Pine.BSF.4.33.0104242326210.4451-100000@mobile.hub.org
Whole thread Raw
In response to Re: Re: refusing connections based on load ...  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Responses 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))
List 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 by date:

Previous
From: Lincoln Yeoh
Date:
Subject: Re: Re: refusing connections based on load ...
Next
From: Philip Warner
Date:
Subject: Re: pg_dump