Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Thu, 17 Jan 2002 23:04:09 -0800
From: Brian Pane <bpane@pacbell.net>
Subject: Re: load spikes revisited
To: dev@httpd.apache.org
Message-id: <3C47C8E9.1070006@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
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>

Aaron Bannert wrote:

>On Thu, Jan 17, 2002 at 10:43:18PM -0800, Brian Pane wrote:
>[snip]
>
>>>prefork was changed to do a apr_poll before the accept, even in the single
>>>listen case, on Nov 10.  The polls seem to get added to the herd of selects 
>>>that
>>>wake up several times a second for no real good reason.  We need to get rid 
>>>of
>>>this poll once again.
>>>
>
>We should get rid of the poll() for S_L_U_A, but I think that would
>only treat the symptom, since it would come back when we had multiple
>listeners.
>

But in the multiple listener case, access to the poll will always
be serialized, so we won't be vulnerable to a thundering herd problem,
right?

>  Personally, I think poll() is itself the problem, and my
>theory is that poll() has a thundering hurd problem on this particular
>version of FreeBSD. We can try this out by #undef'ing HAVE_POLL in
>srclib/apr/network_io/unix/poll.c, so we use select() instead, which
>is what we used to do before Nov 10th.
>

Yep, I think the poll is the problem too.  We ought to be
able to remove it altogether in the single-listener case,
though.

--Brian