-CURRENT problems with WCCP/high load
Hello! machine panics under load (800pkt/sec, 600-800 kByte/sec traffik) I got a dual pIII 1Ghz machine with todays -current, ipfirewall_forward option enabled, several Intel Express cards inside. kernel is GENERIC with some stripped drivers, witness, invariants, debugging etc disabled. compiled with -O2 -pipe, no arch flags. running squid with wccp2 patch, loaded modules -- acpi, ipfw, if_gre. on another side is a cisco router which redirects traffic to freebsd box using wccp2. after running several seconds under the load -- 7-10 seconds computer panics with in process swi:net. kernel world compilation run without any failures or crashes -- so i'm sure, that this is a software problem. anyone interested in kernel corefile or not ? I can provide any additional information if anyone interested. please reply directly to my mail address, i'm not on list ) with best regards , Gaspar Chilingarov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fork rate limit
Hello! i was not intended to include following lines to the patch: -- @@ -36,7 +36,7 @@ * SUCH DAMAGE. * *@(#)kern_fork.c8.6 (Berkeley) 4/8/94 - * $FreeBSD: src/sys/kern/kern_fork.c,v 1.130 2002/02/07 23:06:26 peter Exp $ + * $FreeBSD: src/sys/kern/kern_fork.c,v 1.128 2002/01/13 11:57:59 alfred Exp $ */ #include "opt_ktrace.h" @@ -239,9 +239,6 @@ struct forklist *ep; struct filedesc *fd; struct proc *p1 = td->td_proc; -struct thread *td2; -struct kse *ke2; -struct ksegrp *kg2; GIANT_REQUIRED; -- please remove them before applying patch. -- Gaspar Chilingarov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fork rate limit
Hi there!
I've implemented suggested limits, and if you are interested, you can
try attached patch, if it's OK, i will submit it to PR database.
Two new RLIMIT_ constants added, that control how many processes spawn
in which period. The only place from where you can set limits is a
login.conf. Also fork rate-limit does not affect processes which belong
to root.
Patch is created against 10 Feb 20:00 UTC sources.
copy it to /usr/src and run 'patch -p1 < diffi'
--
Gaspar Chilingarov
diff -r -u /usr/src/lib/libc/sys/getrlimit.2 src/lib/libc/sys/getrlimit.2
--- /usr/src/lib/libc/sys/getrlimit.2 Mon Oct 1 21:09:01 2001
+++ src/lib/libc/sys/getrlimit.2Mon Feb 11 00:32:16 2002
@@ -98,6 +98,13 @@
The maximum size (in bytes) of socket buffer usage for this user.
This limits the amount of network memory, and hence the amount of
mbufs, that this user may hold at any time.
+.It Li RLIMIT_FORKPROC
+The maximum count of processes that user can start in RLIMIT_PERIOD seconds.
+This limit does not apply to superuser. Zero value is not allowed.
+Only rlim_max (hard limit) value is used, when applying limits.
+.It Li RLIMIT_FORKPERIOD
+Amount of seconds, to which applies RLIMIT_FORKPROC. This value cannot be changed by
+non-superuser. Zero value is not allowed.
+Only rlim_max (hard limit) value is used, when applying limits.
.El
.Pp
A resource limit is specified as a soft limit and a hard limit. When a
diff -r -u /usr/src/lib/libutil/login.conf.5 src/lib/libutil/login.conf.5
--- /usr/src/lib/libutil/login.conf.5 Fri Nov 16 08:39:43 2001
+++ src/lib/libutil/login.conf.5Mon Feb 11 00:31:01 2002
@@ -164,6 +164,8 @@
.It "openfiles number Maximum number of open files per process.
.It "sbsizesizeMaximum permitted socketbuffer size.
.It "stacksize sizeMaximum stack size limit.
+.It "forkproc number Maximum number of process allowed to start in
+'forkperiod' seconds.
+.It "forkperiodnumber
.El
.Pp
These resource limit entries actually specify both the maximum
diff -r -u /usr/src/lib/libutil/login_class.c src/lib/libutil/login_class.c
--- /usr/src/lib/libutil/login_class.c Mon Oct 1 03:35:07 2001
+++ src/lib/libutil/login_class.c Mon Feb 11 00:31:01 2002
@@ -47,16 +47,18 @@
rlim_t (*who)(login_cap_t *, const char *, rlim_t, rlim_t);
int why;
} resources[] = {
-{ "cputime", login_getcaptime, RLIMIT_CPU },
-{ "filesize", login_getcapsize, RLIMIT_FSIZE},
-{ "datasize", login_getcapsize, RLIMIT_DATA },
-{ "stacksize",login_getcapsize, RLIMIT_STACK},
-{ "memoryuse",login_getcapsize, RLIMIT_RSS },
-{ "memorylocked", login_getcapsize, RLIMIT_MEMLOCK },
-{ "maxproc", login_getcapnum, RLIMIT_NPROC},
-{ "openfiles",login_getcapnum, RLIMIT_NOFILE },
-{ "coredumpsize", login_getcapsize, RLIMIT_CORE },
-{ "sbsize", login_getcapsize,RLIMIT_SBSIZE },
+{ "cputime", login_getcaptime, RLIMIT_CPU },
+{ "filesize", login_getcapsize, RLIMIT_FSIZE },
+{ "datasize", login_getcapsize, RLIMIT_DATA},
+{ "stacksize",login_getcapsize, RLIMIT_STACK },
+{ "memoryuse",login_getcapsize, RLIMIT_RSS },
+{ "memorylocked", login_getcapsize, RLIMIT_MEMLOCK },
+{ "maxproc", login_getcapnum, RLIMIT_NPROC },
+{ "openfiles",login_getcapnum, RLIMIT_NOFILE },
+{ "coredumpsize", login_getcapsize, RLIMIT_CORE},
+{ "sbsize", login_getcapsize,RLIMIT_SBSIZE },
+{ "forkproc", login_getcapnum, RLIMIT_FORKPROC },
+{ "forkperiod", login_getcapnum, RLIMIT_FORKPERIOD },
{ NULL, 0,0 }
};
diff -r -u /usr/src/sys/kern/kern_fork.c src/sys/kern/kern_fork.c
--- /usr/src/sys/kern/kern_fork.c Fri Feb 8 03:06:26 2002
+++ src/sys/kern/kern_fork.cMon Feb 11 00:27:18 2002
@@ -36,7 +36,7 @@
* SUCH DAMAGE.
*
* @(#)kern_fork.c 8.6 (Berkeley) 4/8/94
- * $FreeBSD: src/sys/kern/kern_fork.c,v 1.130 2002/02/07 23:06:26 peter Exp $
+ * $FreeBSD: src/sys/kern/kern_fork.c,v 1.128 2002/01/13 11:57:59 alfred Exp $
*/
#include "opt_ktrace.h"
@@ -239,9 +239,6 @@
struct forklist *ep;
struct filedesc *fd;
struct proc *p1 = td->td_proc;
- struct thread *td2;
- struct kse *ke2;
- struct ksegrp *kg2;
GIANT_REQUIRED;
@@ -249,12 +246,25 @@
if ((flags & (RFFDG|RFCFDG)) == (RFFDG|RFCFDG))
return (EINVA
Re: fork rate limit
-> Date: Sat, 2 Feb 2002 12:52:24 -0800 (PST) -> From: Matthew Dillon <[EMAIL PROTECTED]> -> To: Gaspar Chilingarov <[EMAIL PROTECTED]> -> Cc: [EMAIL PROTECTED] -> Subject: Re: fork rate limit -> -> :Hi! -> : -> :Is it reasonable to administratively limit users' ability to call fork -> :too other ? Users can take away too much CPU time even if you have ^^^ sorry, often, it's my typo :) -> :limited them by login.conf 'cputime' limit - just forking lightweight -> :processes too often. -> : -> :If it seems good thing to do, i'll try to code it and submit patches for -> :-current. -> : -> :I think this limit must go to struct uidinfo, am i right ? -> :Also i need to store per-user counters somewhere, can i place it there? -> : -> :-- -> :Gaspar Chilingarov -> -> Well, we did make fork inherit the parent process's current -> priority, so if a parent process forks() a lot it and its -> children should get less cpu. Beyond that the system can't really -> tell whether the cpu use is something the sysad wants (i.e. sa -> y it's a web server) or something the sysad doesn't want (an -> abusive user). -> -> -Matt i think SA can easily tell tehe system by assigning different uids assigned to them :) I've got such situation on our free shellbox set up in the university - some newbies were kidding with old while(1) fork(); attack. Finnaly they got hit by memory limits set up for each user, but anyway they were taking a lot of processor time. I prefer to limit some uid's ability to do many forks in some short period - like 'no more than 200 forks in 10 seconds' or smthng like this. -- Gaspar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fork rate limit
Hi! Is it reasonable to administratively limit users' ability to call fork too other ? Users can take away too much CPU time even if you have limited them by login.conf 'cputime' limit - just forking lightweight processes too often. If it seems good thing to do, i'll try to code it and submit patches for -current. I think this limit must go to struct uidinfo, am i right ? Also i need to store per-user counters somewhere, can i place it there? -- Gaspar Chilingarov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
