Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id AAA06454; Sat, 13 Sep 1997 00:23:52 -0700 (PDT) Received: from transpect.local.net (rickf@transpect.netnation.com [204.174.223.3]) by hyperreal.org (8.8.5/8.8.5) with ESMTP id AAA06450 for ; Sat, 13 Sep 1997 00:23:48 -0700 (PDT) Received: from localhost (rickf@localhost) by transpect.local.net (8.8.5/8.8.5) with SMTP id AAA03195; Sat, 13 Sep 1997 00:21:30 -0700 X-Authentication-Warning: transpect.local.net: rickf owned process doing -bs Date: Sat, 13 Sep 1997 00:21:29 -0700 (PDT) From: Rick Franchuk X-Sender: rickf@transpect.local.net To: Dean Gaudet cc: dgaudet@hyperreal.org, apache-bugdb@apache.org Subject: Re: general/1107: Runaway httpd process under heavy load In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: apache-bugdb-owner@apache.org Precedence: bulk On Sat, 13 Sep 1997, Dean Gaudet wrote: > Linux kernels by default are maxed at 512 processes, and half of that is > the per-userid limit. There's a define you can tweak in > /usr/src/linux/include/linux somewhere NR_TASKS I believe. You can crank > it up to 4000 or so in the 2.0.x series. > > I've looked at the code for select in the kernel, and EFAULT should only > occur if you pass it a bogus pointer ... which we'd have a hard time doing > considering we're passing it a statically allocated thing. > > When I get a chance I'll try a heavy load with lots of CGIs just for kicks > and see what happens. AHA! /usr/include/linux/tasks.h has it. You wouldn't believe how long I looked for that before jimmying it with csh. ;) Time to get a new pair of glasses, looks like. re: bogus pointer - Hmmm... it'd be a relatively trivial thing (from here, anywaysy) to make a debug-compiled process lock up and attach gdb to it, maybe see where that pointer is pointing to. I've got an odd hunch that task limit may somehow affect the fault status of the select statement, so when bombarding your test machine, see if you can make it run some cgis and get into that 'cannot spawn child process' area. Maybe you'll have more luck getting it to lock. Or, if you want to get fancy, make the child kill itself with SEGV and dump the core someplace. ;) --- __________________________________________ | | | Rick Franchuk - TranSpecT Consulting | |_______ _______| \mailto:rickf@transpect.net/