Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Sender: gregames@Mail.MeepZor.Com
Message-ID: <3C3CC772.CE21BF6E@remulak.net>
Date: Wed, 09 Jan 2002 17:42:58 -0500
From: Greg Ames <gregames@remulak.net>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: 2.0.29 high load avg
References: <3C3BB67A.3EE12176@remulak.net>
 <20020109040719.GN14870@ebuilt.com> <3C3C5F6F.B90D1FA5@remulak.net>
 <20020109195833.GX14870@ebuilt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Justin Erenkrantz wrote:

> Yeah, I see "mutex" in the STATE column.  walla is a FreeBSD-CURRENT
> system that at that point was running with prefork (threads
> disabled).  (It's also the box where I'm doing worker/thread testing.)
> I can state that I've seen similar behavior "RUN" for all briefly,
> then select, accept, etc.

I never see "mutex", but daedalus's production config listens on port 80 only,
so there's no accept mutex.  Was walla listening on multiple ports?

> This type of behavior sounds like there is a global lock that is
> being held by one process that causes everyone to wait.  Once that
> lock is released, everyone finishes.  -- justin

hmmm, that's an interesting theory.  It would definitely spike the run queue,
and might cause visible cpu spikes.  But in daedalus's case, I don't know what
the global lock equivalent would be.  

Greg