Re: [HACKERS] refusing connections based on load ...
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 enabled/disable that feature? Because it's tied to a GNU getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... But what's in FreeBSD's standard library isn't GNU. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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, 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. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... But what's in FreeBSD's standard library isn't GNU. Wouldn't matter if it was, its part of the OSs standard library ... unless you mean to pull it in and use it with the distribution, which I think might be a bad idea ... if we pull anything in, sendmail's would be best ... FreeBSD's will have had anything required for non-FreeBSD systems yanked out, if it was ever there, while sendmail's already has all the 'hooks' in it ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections based on load ...
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 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. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... But what's in FreeBSD's standard library isn't GNU. Wouldn't matter if it was, its part of the OSs standard library ... unless you mean to pull it in and use it with the distribution, which I think might be a bad idea ... if we pull anything in, sendmail's would be best ... FreeBSD's will have had anything required for non-FreeBSD systems yanked out, if it was ever there, while sendmail's already has all the 'hooks' in it ... That wasn't what I was saying at all. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 has merit to make use of? I'll play with it if so ... I agree that it would be useful. Even more useful would be soft load shedding, where once some load average level is exceeded the postmaster delays a bit (proportionately) before accepting a connection. Or have the load check on AtXactStart, and delay new transactions until load is back below x, where x is configurable per user/group plus some per database scaling factor. How is this different than limiting the number of backends that can be running at once? It would seem to me that a user that has a delayed startup is going to think there's something wrong with the server and keep trying, where as a message like too many clients - try again later explains what's really going on. len morgan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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
better.
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.
I believe vmstat is fairly standard. For those systems
which don't support vmstat, it could be faked with a shell script.
You could write the specific code to handle each arch, but it's
a royal pain, because it's so different for many archs.
Another possibility could be to read from /proc for those systems
that support /proc. But I think this will be more variable than
the output from vmstat. Vmstat also has the added benefit of
providing other information.
I agree with Tom about not wanting to open up /dev/kmem,
due to potential security problems.
Neal
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] refusing connections based on load ...
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. On the other hand, I think almost all of this stuff can and should be done outside of postmaster. Here is the 0-change version, for rejecting connections, and for operating systems that have built-in firewall capability, such as FreeBSD: a standalone daemon that adds a reject rule for the Postgres port when the load gets too high, and drops that rule when the load goes back down. Now here's the small-change version: add support to Postgres for a SET command or similar way to say stop accepting connections, or set accept/transaction delay to X. Write a standalone daemon which monitors the load and issues commands to Postgres as necessary. That daemon may need extra privileges, but it is small, auditable, and doesn't talk to the outside world. It's probably better to include in the Postgres protocol support for accepting (TCP-wise) a connection, then closing it with an error message, because this daemon needs to be able to connect to tell it to let users in again. It's probably as simple as always letting the superuser in. The latter is nicer in a number of ways. Persistent connections were already mentioned - rejecting new connections may not be a good enough solution there. With a fancier approach, you could even hang up on some existing connections with an appropriate message, or just NOTICE them that you're slowing them down or you'd like them to go away voluntarily. From a web-hosting standpoint, someday it would be nifty to have per-user-per-connection limits, so I could put up a couple of big PG servers and only allow user X one connection, which can't use more than Y amount of RAM, and passes a scheduling hint to the OS so it shares CPU time with other economy-class users, which can be throttled down to 25% of what ultra-mega-hosting users get. Simple load shedding is a baby step in the right direction. If nothing else, it will cast a spotlight on some of the problem areas. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 we can already do that and it's not what we're after here. The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. Additionally, the concurrent transaction limit would only be useful on setups that have a lot of idle transactions. Those setups exist, but not everywhere. To me, both of these approaches are in the if you don't like it, don't use it category. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 systems, the finest-grain load average that you can get is a 1-minute average. This will lose both on the ramp up (by the time you realize you overdid it, you've let *way* too many xacts through the starting gate) and on the ramp down (you'll hold off xacts for circa a minute after the crunch is past). (2) You can also get shorter-time-frame CPU usage numbers (at least, most versions of top(1) seem to display such things) but CPU load is really not very helpful for measuring how badly the system is thrashing. Postgres tends to beat your disks into the ground long before it pegs the CPU. Too bad there's no disk usage numbers. However, there is another possibility that would be simple to implement and perfectly portable: allow the dbadmin to impose a limit on the number of simultaneous concurrent transactions. (Setting this equal to the max allowed number of backends would turn off the limit.) That way, you could have umpteen open connections, but you could limit how many of them were actually *doing* something at any given instant. If more than N try to start transactions at the same time, the later ones have to wait for the earlier ones to finish before they can start. This'd be trivial to do with a semaphore initialized to N --- P() it in StartTransaction and V() it in Commit/AbortTransaction. 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. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 control the absolute load of the PostgreSQL server, but we can already do that and it's not what we're after here. The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. Additionally, the concurrent transaction limit would only be useful on setups that have a lot of idle transactions. Those setups exist, but not everywhere. To me, both of these approaches are in the if you don't like it, don't use it category. 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 ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] refusing connections based on load ...
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 will create a lot of portability headaches for no real gain. If it were something we could just do and forget, I would not object --- but the porting issues will create a LOT more work than I think this can possibly be worth. The fact that the work is distributed and will mostly be incurred by people other than the ones advocating the change doesn't improve matters. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 applicationlevel.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. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] refusing connections based on load ...
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 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 not allow us to do it very well. I think this will create a lot of portability headaches for no real gain. If it were something we could just do and forget, I would not object --- but the porting issues will create a LOT more work than I think this can possibly be worth. The fact that the work is distributed and will mostly be incurred by people other than the ones advocating the change doesn't improve matters. As I mentioned, getloadavg() appears to be support on 3 of the primary platforms we work with, so I'd say for most installations, portability issues aren't an issue ... Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? If ( loadavg available on OSenabled in postgresql.conf ) operate on it } else ( loadavg not available on OS enabled ) noop with a WARN level error that its not available } ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] refusing connections based on load ...
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 problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 every platform they use ... and a growing number of platforms appear to have the mechanisms already built into their C libraries ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] refusing connections based on load ...
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,
which is what it'd take to run the sendmail loadaverage code on most
platforms...
This program:
#include stdio.h
int main()
{
double la[3];
if (getloadavg(la, 3) == -1)
perror(getloadavg);
printf(%f %f %f\n, la[0], la[1], la[2]);
return 0;
}
works unprivileged on Linux 2.2 and FreeBSD 4.3. Rumour[*] also has it
that there is a way to do this on Solaris and HP-UX 9. So I think that
covers enough users to be worthwhile.
[*] - Autoconf AC_FUNC_GETLOADAVG
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] refusing connections based on load ...
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 sys/loadavg.h
int getloadavg(double loadavg[], int nelem);
DESCRIPTION
How hard would it be to knock up code that, by default, ignores loadavg,
but if, say, set in postgresql.conf:
loadavg = 4
it will just refuse connections?
On Tue, 24 Apr 2001, Peter Eisentraut wrote:
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,
which is what it'd take to run the sendmail loadaverage code on most
platforms...
This program:
#include stdio.h
int main()
{
double la[3];
if (getloadavg(la, 3) == -1)
perror(getloadavg);
printf(%f %f %f\n, la[0], la[1], la[2]);
return 0;
}
works unprivileged on Linux 2.2 and FreeBSD 4.3. Rumour[*] also has it
that there is a way to do this on Solaris and HP-UX 9. So I think that
covers enough users to be worthwhile.
[*] - Autoconf AC_FUNC_GETLOADAVG
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections 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? The application stops working. Is this really better than having slow response time because the server is thrashing? That's exactly the point why I suggested to delay transaction starts instead. The client app allways gets the connection. Doing dialog steps inside of open transactions is allways a bad design, leading to a couple of problems (coffee break with open locks), so we can assume that if an application starts a transaction, it'll keep this one backend as busy as possible until the transactions end. Processing too many transactions parallel is what get's the system into heavy swapping and exponential usage of resources. So if we delay starting transactions if the system load is above the limit, we probably speedup the overall per transaction response time, increasing the througput. And that's what this discussion is all about, no? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] refusing connections based on load ...
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? The application stops working. Is this really better than having slow response time because the server is thrashing? The concept is just as dubious as the concept of rejecting clients based on how many clients are already connected. There are some technical reasons for the latter, but it is still used as an administrative tool. The rule is, if you don't like it, don't use it. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] refusing connections based on load ...
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 play with it if so ... I agree that it would be useful. Even more useful would be soft load shedding, where once some load average level is exceeded the postmaster delays a bit (proportionately) before accepting a connection. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections based on load ...
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 has merit to make use of? I'll play with it if so ... I agree that it would be useful. Even more useful would be soft load shedding, where once some load average level is exceeded the postmaster delays a bit (proportionately) before accepting a connection. Or have the load check on AtXactStart, and delay new transactions until load is back below x, where x is configurable per user/group plus some per database scaling factor. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] refusing connections based on load ...
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 the sendmail loadaverage code on most platforms... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] refusing connections based on load ...
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 read /dev/kmem, which is what it'd take to run the sendmail loadaverage code on most platforms... Actually, not totally accurate ... sendmail has a 'RunAs' option for those that don't wish to have it run as root, and still works for the loadavg stuff, to the best of my knowledge (its an option I haven't played with yet) ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 still requires privileges beyond those of mere mortals (as does listening on port 25, last I checked). On my HPUX box: $ ls -l /dev/kmem crw-r- 1 binsys 3 0x01 Jun 10 1996 /dev/kmem so postgres would have to run setuid bin or setgid sys to read the load average. Either one is equivalent to giving an attacker the keys to the kingdom (overwrite a few key /usr/bin/ executables and wait for root to run one...) 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 your kernel memory? It wouldn't take too much effort to sniff passwords, for example. 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 users. By definition you do not trust them, eh? 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 better. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 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.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
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 your kernel memory? It wouldn't take too much effort to sniff passwords, for example. On Linux you can get the load average by doing `cat /proc/loadavg'. On NetBSD you can get the load average via a sysctl. On those systems and others the uptime program is neither setuid nor setgid. 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 better. That is the way to do it on systems where obtaining the load average requires special privileges. But do you really need the load average once a minute? The load average printed by uptime is just as accurate as the load average obtained by examining the kernel. Ian ---(end of broadcast)--- TIP 652: Life is a serious burden, which no thinking, humane person would wantonly inflict on someone else. -- Clarence Darrow ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] refusing connections based on load ...
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 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 still requires
privileges beyond those of mere mortals (as does listening on port 25,
last I checked).
On my HPUX box:
$ ls -l /dev/kmem
crw-r- 1 binsys 3 0x01 Jun 10 1996 /dev/kmem
so postgres would have to run setuid bin or setgid sys to read the load
average. Either one is equivalent to giving an attacker the keys to the
kingdom (overwrite a few key /usr/bin/ executables and wait for root to
run one...)
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 your kernel memory? It wouldn't
take too much effort to sniff passwords, for example.
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 users. By definition you do not trust them, eh?
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
better.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections based on load ...
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 let an attacker have open-ended rights to read your kernel memory? It wouldn't take too much effort to sniff passwords, for example. On Linux you can get the load average by doing `cat /proc/loadavg'. On NetBSD you can get the load average via a sysctl. On those systems and others the uptime program is neither setuid nor setgid. Good call ... FreeBSD has it also, and needs no special privileges ... just checked, and the sysctl command isn't setuid/setgid anything, so I'm guessing that using sysctl() to pull these values shouldn't create any security issues on those systems that support it ? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] refusing connections based on load ...
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(), 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
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
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 users. By definition you do not trust them, eh? No. It's not a case of trust, but of providing an adaptive way to keep performance reasonable. The users may have no independent way to cooperate to limit load, but the DB can provide that. 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 better. Yes, this alternative looks much better to me. On Linux you have the much more efficient alternative, /proc/loadavg. (I wouldn't use system(), though.) Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
