Re: refusing connections based on load ...

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: refusing connections based on load ...
Date: 2001-04-25 21:03:31
Message-ID: 200104252103.QAA30477@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The Hermit Hacker wrote:
> Agreed ... by default, the loadavg method could be set to zero, to ignore
> ... I don't care if I'm off by 1min before I catch the increase, the fact
> is that I have caught it, and prevent any new ones coming in until it
> drops off again ...
>
> Make it two variables:
>
> transla
> rejectla
>
> if transla is hit, restrict on transactions, letting others connect, but
> putting them on hold while the la drops again ... if it goes above
> rejectla, refuse new connections altogether ...
>
> so now I can set something like:
>
> transla = 8
> rejectla = 16
>
> but if loadavg goes above 16, I want to get rid of what is causing the
> load to rise *before* adding new variables to the mix that will cause it
> to rise higher ...
>
> and your arg about permissions (Tom's, not Peter's) is moot in at least 3
> of the major systems (Linux, *BSD and Solaris) as there is a getloadavg()
> function in all three for doing this ...

I've just recompiled my php4 module to get sysvsem support
and limited the number of concurrent DB transactions on the
application level. The (not yet finished) TPC-C
implementation I'm working on scales about 3-4 times better
now. That's an improvement!

This proves that limiting the number of concurrently running
transactions is sufficient to keep the system load down.
Combined these two look as follows:

- We start with a fairly high setting in the semaphore.

- When the system load exceeds the high-watermark, we don't
increment the semaphore back after transaction end (need
to ensure that at least a small minimum of xacts is left,
but that's easy).

- When the system goes back to normal load level, we slowly
increase the semaphore again.

This way we might have some peek pushing the system against
the wall for a moment. If that doesn't go away quickly, we
just delay users (who see some delay anyway actually).

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Burton 2001-04-25 21:09:46 Re: Any optimizations to the join code in 7.1?
Previous Message The Hermit Hacker 2001-04-25 20:51:42 Re: refusing connections based on load ...