From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | The Hermit Hacker <scrappy(at)hub(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: refusing connections based on load ... |
Date: | 2001-04-24 04:39:29 |
Message-ID: | 3.0.5.32.20010424123929.00d85100@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 03:09 PM 23-04-2001 -0300, you wrote:
>
>Anyone thought of implementing this, similar to how sendmail does it? If
>load > n, refuse connections?
>
>Basically, if great to set max clients to 256, but if load hits 50 as a
>result, the database is near to useless ... if you set it to 256, and 254
>idle connections are going, load won't rise much, so is safe, but if half
>of those processes are active, it hurts ...
Sorry, but I still don't understand the reasons why one would want to do
this. Could someone explain?
I'm thinking that if I allow 256 clients, and my hardware/OS bogs down when
60 users are doing lots of queries, I either accept that, or figure that my
hardware/OS actually can't cope with that many clients and reduce the max
clients or upgrade the hardware (or maybe do a little tweaking here and
there).
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.
Cheerio,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2001-04-24 04:53:55 | Re: refusing connections based on load ... |
Previous Message | The Hermit Hacker | 2001-04-24 04:23:41 | Re: refusing connections based on load ... |