From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)yahoo(dot)com> |
Cc: | The Hermit Hacker <scrappy(at)hub(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: refusing connections based on load ... |
Date: | 2001-04-25 21:12:02 |
Message-ID: | 6088.988233122@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck <JanWieck(at)yahoo(dot)com> writes:
> 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 is a nice way of dealing with the slow reaction time of the
load average --- you don't let it directly drive the decision about
when to start a new transaction, but instead let it tweak the ceiling
on number of concurrent xacts. I like it.
You probably don't need to have any additional "slowness" in the loop
other than the inherent averaging in the kernel's load average.
I'm still concerned about portability issues, and about whether load
average is really the right number to be looking at, however.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-04-25 21:14:56 | Re: refusing connections based on load ... |
Previous Message | Jan Wieck | 2001-04-25 21:10:40 | Re: Cursor support in pl/pg |