From owner-freebsd-hackers Sat May 31 00:32:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11816 for hackers-outgoing; Sat, 31 May 1997 00:32:17 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA11811 for ; Sat, 31 May 1997 00:32:15 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id AAA21045 for ; Sat, 31 May 1997 00:32:01 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA21744; Sat, 31 May 1997 08:57:29 +0200 From: Luigi Rizzo Message-Id: <199705310657.IAA21744@labinfo.iet.unipi.it> Subject: Re: WHy does Appache eat my system? To: julian@whistle.com (Julian Elischer) Date: Sat, 31 May 1997 08:57:28 +0200 (MET DST) Cc: julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <338F9023.41C67EA6@whistle.com> from "Julian Elischer" at May 30, 97 07:42:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been doing some kernel profiling on a freeBSD system, trying > to figure out why I have 0% idle and 60% in the kernel. > I haven't tracked it all down but here are a few bits of the > traces... > > Apache seems to be the main culprit. > > does anyoen who really knows apache heve any suggestions? Not that I know apache very well, but I think it uses the standard technique for multiple servers: all issue an accept() (or a select on the socket), all are woken up when the SYN comes in, then only the first one is able to successfully complete the request. In fact, this mechanism is used to synchronize the multiple servers among themselves. It would be nice to wake up only the process which actually completes the accept() successfully, but it seems a bit hard to achieve the desired result since the kernel scans all blocked processes before one has a chance to run the upper part of the accept (or this is even a subsequent syscall if using select()). The best one can do is (probably) to implement a modified select() which only wakes up the first process blocked (hoping it will be able to complete the accept() successfully). Maybe this is not too hard, but it is non-standard. Other than that, perhaps you could look at what is done in the 'team' program: there, multiple processes share the same i/o descriptor and read from them in a round-robin fashion. They probably use a different mechanism to synchronize (e.g. signals; you could also use sockets among processes) and processes are connected in a round-robin fashion. But it is non trivial to accomodate dynamic creation of processes. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________