Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Wed, 25 Apr 2001, The Hermit Hacker wrote:
>> On Wed, 25 Apr 2001, Vince Vielhaber wrote:
>>
> On Wed, 25 Apr 2001, Tom Lane wrote:
> Because it's tied to a GNU getloadavg.c implementation, which we'd have
> license problems with using.
>
> It's p
Tom Lane wrote:
> A less dangerous way of approaching it might be to have an option
> whereby the postmaster invokes 'uptime' via system() every so often
> (maybe once a minute?) and throttles on the basis of the results.
> The reaction time would be poorer, but security would be a whole lot
> be
>Nathan Myers wrote:
>> On Mon, Apr 23, 2001 at 03:09:53PM -0300, The Hermit Hacker wrote:
>> >
>> > Anyone thought of implementing this, similar to how sendmail does it?
If
>> > load > n, refuse connections?
>> > ...
>> > If nobody is working on something like this, does anyone but me feel
that
>
On Thu, 26 Apr 2001, The Hermit Hacker wrote:
> On Thu, 26 Apr 2001, Vince Vielhaber wrote:
>
> > On Wed, 25 Apr 2001, The Hermit Hacker wrote:
> >
> > > On Wed, 25 Apr 2001, Vince Vielhaber wrote:
> > >
> > > > On Wed, 25 Apr 2001, Tom Lane wrote:
> > > >
> > > > > The Hermit Hacker <[EMAIL PROT
On Thu, 26 Apr 2001, Vince Vielhaber wrote:
> On Wed, 25 Apr 2001, The Hermit Hacker wrote:
>
> > On Wed, 25 Apr 2001, Vince Vielhaber wrote:
> >
> > > On Wed, 25 Apr 2001, Tom Lane wrote:
> > >
> > > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > > Autoconf has a 'LOADAVG' check already
On Wed, 25 Apr 2001, The Hermit Hacker wrote:
> On Wed, 25 Apr 2001, Vince Vielhaber wrote:
>
> > On Wed, 25 Apr 2001, Tom Lane wrote:
> >
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > Autoconf has a 'LOADAVG' check already, so what is so problematic about
> > > > using that to enab
On Wed, 25 Apr 2001, Tom Lane wrote:
> I'm still concerned about portability issues, and about whether load
> average is really the right number to be looking at, however.
Its worked for Sendmail for how many years now, and the code is there to
use, with all "portability issues resolved for ever
On Wed, 25 Apr 2001, Vince Vielhaber wrote:
> On Wed, 25 Apr 2001, Tom Lane wrote:
>
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > Autoconf has a 'LOADAVG' check already, so what is so problematic about
> > > using that to enabled/disable that feature?
> >
> > Because it's tied to a GNU
On Wed, 25 Apr 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Autoconf has a 'LOADAVG' check already, so what is so problematic about
> > using that to enabled/disable that feature?
>
> Because it's tied to a GNU getloadavg.c implementation, which we'd have
> license pr
On Wed, 25 Apr 2001, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The idea behind the load average based approach is
> > to make the postmaster respect the situation of the overall system.
>
> That'd be great if we could do it, but as I pointed out, the available
> stats do
Jan Wieck <[EMAIL PROTECTED]> 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 t
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Autoconf has a 'LOADAVG' check already, so what is so problematic about
> using that to enabled/disable that feature?
Because it's tied to a GNU getloadavg.c implementation, which we'd have
license problems with using.
regar
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:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The idea behind the load average based approach is
> to make the postmaster respect the situation of the overall system.
That'd be great if we could do it, but as I pointed out, the available
stats do not allow us to do it very well.
I think this wi
On Wed, 25 Apr 2001, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > A conncurrent-xacts limit isn't perfect of course, but I think it'd
> > be pretty good, and certainly better than anything based on the
> > available load-average numbers.
>
> The concurrent transaction limit would allow you to
Jan Wieck and I talked about this for awhile yesterday, and we came to
the conclusion that load-average-based throttling is a Bad Idea. Quite
aside from the portability and permissions issues that may arise in
getting the numbers, the available numbers are the wrong thing:
(1) On most Unix syste
Tom Lane writes:
> A conncurrent-xacts limit isn't perfect of course, but I think it'd
> be pretty good, and certainly better than anything based on the
> available load-average numbers.
The concurrent transaction limit would allow you to control the absolute
load of the PostgreSQL server, but w
The whole argument over how to get load averages seems rather silly,
and it's moot if the idea of using the load information to alter
PG behavior is rejected.
I personally have no use for it, but I don't think it's a bad idea in
general. Particularly given future redundancy/load sharing features
Doug McNaught writes:
> 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?
Doug McNaught wrote:
> 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? Th
Apparently so under Solaris ...
hestia:/> uname -a
SunOS hestia 5.7 Generic_106542-12 i86pc i386 i86pc
C Library Functionsgetloadavg(3C)
NAME
getloadavg - get system load averages
SYNOPSIS
#include
int getloadavg(double loadavg[], int nelem);
Tom Lane writes:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > sendmail does it now, and, apparently relatively portable across OSs ...
>
> sendmail expects to be root. It's unlikely (and very undesirable) that
> postgres will be installed with adequate privileges to read /dev/kmem,
> whic
On Mon, Apr 23, 2001 at 10:50:42PM -0400, Tom Lane wrote:
> Basically, if we do this then we are abandoning the notion that Postgres
> runs as an unprivileged user. I think that's a BAD idea, especially in
> an environment that's open enough that you might feel the need to
> load-throttle your us
Tom Lane <[EMAIL PROTECTED]> 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()
On 23 Apr 2001, Ian Lance Taylor wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > On Linux and BSD it seems to be more common to put /dev/kmem into a
> > specialized group "kmem", so running postgres as setgid kmem is not so
> > immediately dangerous. Still, do you think it's a good idea to l
other then a potential buffer overrun, what would be the problem with:
open(kmem)
read values
close(kmem)
?
I would think it would be less taxing to the system then doing a system()
call, but still effectively as safe, no?
On Mon, 23 Apr 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROT
Tom Lane <[EMAIL PROTECTED]> writes:
> On Linux and BSD it seems to be more common to put /dev/kmem into a
> specialized group "kmem", so running postgres as setgid kmem is not so
> immediately dangerous. Still, do you think it's a good idea to let an
> attacker have open-ended rights to read yo
> 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.
> I beli
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On Mon, 23 Apr 2001, Tom Lane wrote:
>> sendmail expects to be root.
> Actually, not totally accurate ... sendmail has a 'RunAs' option for those
> that don't wish to have it run as root,
True, it doesn't *have* to be root, but the loadavg code sti
On Mon, 23 Apr 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > sendmail does it now, and, apparently relatively portable across OSs ...
>
> sendmail expects to be root. It's unlikely (and very undesirable) that
> postgres will be installed with adequate privileges to re
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> sendmail does it now, and, apparently relatively portable across OSs ...
sendmail expects to be root. It's unlikely (and very undesirable) that
postgres will be installed with adequate privileges to read /dev/kmem,
which is what it'd take to run th
Nathan Myers wrote:
> On Mon, Apr 23, 2001 at 03:09:53PM -0300, The Hermit Hacker wrote:
> >
> > Anyone thought of implementing this, similar to how sendmail does it? If
> > load > n, refuse connections?
> > ...
> > If nobody is working on something like this, does anyone but me feel that
> > it
On Mon, Apr 23, 2001 at 03:09:53PM -0300, The Hermit Hacker wrote:
>
> Anyone thought of implementing this, similar to how sendmail does it? If
> load > n, refuse connections?
> ...
> If nobody is working on something like this, does anyone but me feel that
> it has merit to make use of? I'll
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 mu
34 matches
Mail list logo
