Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3C3CCB09.9010400@cnet.com>
Date: Wed, 09 Jan 2002 14:58:17 -0800
From: Brian Pane <brian.pane@cnet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
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> <3C3CC772.CE21BF6E@remulak.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Greg Ames wrote:

>Justin Erenkrantz wrote:
>
...

>>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.  
>

On FreeBSD, is there a way to look at the syscalls active within the
kernel at a point in time?  On Solaris, running "adb -k" and using the
"$<threadlist" macro will give a stack trace of each thread in the
kernel--a mix of internal kernel threads and the threads executing the
internal implementation of each currently executing syscall.  If you
have something similar in FreeBSD, it should show whether daedalus has
a lot of syscalls blocked on, say, some global mutex within the kernel.

--Brian