Re: refusing connections based on load ...

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> > Rather than do system('uptime') and incur the process start-up each time,
> > you could do fp = popen('vmstat 60', 'r'), then just read the fp.
>
> popen doesn't incur a process start? Get real. But you're right, popen()
> is the right call not system(), because you need to read the stdout.

Tom,

I think the point here is that the 'vmstat' process, once started,
will keep printing status output every 60 seconds (if invoked as
above) so you don't have to restart it every minute, just read the
pipe.

> > I believe vmstat is fairly standard.
>
> Not more so than uptime --- and the latter's output format is definitely
> less variable across platforms. The HPUX man page goes so far as to say
>
> WARNINGS
> Users of vmstat must not rely on the exact field widths and spacing of
> its output, as these will vary depending on the system, the release of
> HP-UX, and the data to be displayed.
>
> and that's just for *one* platform.

A very valid objection. I'm also dubious as to the utility of the
whole concept. What happens when Sendmail refuses a message based on
load? It is requeued on the sending end to be tried later. What
happens when PG refuses a new client connection based on load? The
application stops working. Is this really better than having slow
response time because the server is thrashing?

I guess my point is that Sendmail is a store-and-forward situation
where the mail system can "catch up" once the load returns to normal.
Whereas, I would think, the majority of PG installations want a
working database, and whether it's refusing connections due to load or
simply bogged down isn't going to make a difference to users that
can't get their data.

-Doug
--
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time... --Dylan