Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 10681 invoked by uid 500); 18 Jan 2002 07:05:41 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 10668 invoked from network); 18 Jan 2002 07:05:40 -0000 Date: Thu, 17 Jan 2002 23:07:35 -0800 From: Brian Pane Subject: Re: load spikes revisited To: dev@httpd.apache.org Message-id: <3C47C9B7.2050404@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 References: <3C462EDA.482A5BE5@remulak.net> <3C4792A5.3F61C50E@remulak.net> <3C47C406.5060504@pacbell.net> <20020117225350.Y1529@clove.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaron Bannert wrote: >>So is the situation basically this: >> * Single listener unserialized accept is enabled on daedalus, >> * We thus have all the idle httpd procs doing a poll before the >> accept, >> * And the spikes in load happen because of the thundering herd >> waking up from the poll when a connection arrives? >> >>If that's the root cause, then I guess 2.0.29 or later with, say, >>pthread mutex accept serialization should be able to run without >>load spikes on daedalus? >> > >I agree, but I have the same reply as above. This may only hide the >problem. > Right, it will only hide the problem. The real point of trying the accept mutex on daedalus is as a test case to prove or disprove the idea that a thundering herd in poll is the problem. --Brian