when I came in to work today, top on daedalus showed all three load
averages above 27. vmstat -w 5 showed that the number of processes in
the run queue was jumping up to over 350 fairly frequently, and there's
some evidence of spikes in CPU usage. So I bounced us back to httpd
2_0_28, and the bad
D]>
Sent: Wednesday, January 02, 2002 3:14 PM
Subject: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]
> when I came in to work today, top on daedalus showed all three load
> averages above 27. vmstat -w 5 showed that the number of processes in
> the run queue was jum
Greg Ames wrote:
>when I came in to work today, top on daedalus showed all three load
>averages above 27. vmstat -w 5 showed that the number of processes in
>the run queue was jumping up to over 350 fairly frequently, and there's
>some evidence of spikes in CPU usage. So I bounced us back to htt
Bill Stoddard wrote:
>
>SetEnvIf ^TS* ^[a-z].* GET_TIMESTAMP
>Header echo ^TS*
If these are REs, shouldn't that be ^TS.*, at least in the
first one?
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
On Wed, Jan 02, 2002 at 12:46:46PM -0800, Brian Pane wrote:
> Do you have a way to take a snapshot of each httpd process's stack
> backtrace? On Solaris, I'd do this by running /usr/proc/bin/pstack
> on each pid; I don't know if FreeBSD has a similar functionality.
> This would give us a picture
Brian Pane wrote:
> Do you have a way to take a snapshot of each httpd process's stack
> backtrace? On Solaris, I'd do this by running /usr/proc/bin/pstack
> on each pid; I don't know if FreeBSD has a similar functionality.
ummm, let's see:
[gregames@daedalus gregames]$ pstack
bash: pstack: co
Greg Ames wrote:
>Jeff & I discussed how to troubleshoot this baby. Some thoughts:
>* compare trusses and look for abnormalities
>* scrutinize the error logs
>* calculate and log how much CPU time each request takes, the thought
>being that some requests are burning a lot more CPU than they used
Brian Pane wrote:
>
> Greg Ames wrote:
>
> >Jeff & I discussed how to troubleshoot this baby. Some thoughts:
> >* compare trusses and look for abnormalities
> >* scrutinize the error logs
> >* calculate and log how much CPU time each request takes, the thought
> >being that some requests are bu
On Wed, Jan 02, 2002 at 12:52:57PM -0800, Aaron Bannert wrote:
> On Wed, Jan 02, 2002 at 12:46:46PM -0800, Brian Pane wrote:
> > Do you have a way to take a snapshot of each httpd process's stack
> > backtrace? On Solaris, I'd do this by running /usr/proc/bin/pstack
> > on each pid; I don't know
Greg Ames wrote:
>truss doesn't measure time on FreeBSD according to the man page. But
>maybe there are a lot more syscalls in the failing case, so I'll try it.
>
I just took a closer look at the vmstat data, and the syscalls/second
value does indeed spike at the same time as the system CPU uti
Greg Ames wrote:
>
> Brian Pane wrote:
> > One more thought: I graphed the CPU utilization from your vmstat
> > output, and the spike is mostly sys time, not usr. So truss/strace
> > data may be helpful--especially if truss on that platform can measure
> > the time spent in each syscall.
>
>
On Thu, Jan 03, 2002 at 10:40:41AM -0500, Greg Ames wrote:
> ~gregames/2.0.30.truss and ~gregames/2_0_28.truss are available on
> daedalus, if you're interested. The former was created by trussing a
> process while running log replay against the 2.0.30 server on port 8092;
> the latter was a proc
> Brian Pane wrote:
>
> I don't have access to daedalus; is there any way you can make the
> files available via http somewhere?
ps, sorry! I thought all the committers had access; apparently it's
no longer true.
check out http://www.apache.org/~gregames/
I do see some weirdness in 2.0
Aaron Bannert wrote:
> Here's a syscall count printed side-by-side:
Thanks much, Aaron. But we have to be careful - this definately isn't
an apples-to-apples comparison.
> 2.0.282.0.30
>
> 1696 sendfile 1180 gettimeofday
> 920 select
On Thu, Jan 03, 2002 at 11:56:26AM -0500, Greg Ames wrote:
> I do see some weirdness in 2.0.30 with www.apache.org/dyn/closer.cgi -
> it looks like we're doing one byte reads from the pipe to the cgi. I
> don't know yet if 2_0_28 does the same. That's all I've spotted so far,
> except for a coup
Aaron Bannert wrote:
>
> On Thu, Jan 03, 2002 at 11:56:26AM -0500, Greg Ames wrote:
> > I do see some weirdness in 2.0.30 with www.apache.org/dyn/closer.cgi -
> > it looks like we're doing one byte reads from the pipe to the cgi. I
> > don't know yet if 2_0_28 does the same.
2_0_28 does the s
Greg Ames wrote:
>Aaron Bannert wrote:
>
>>On Thu, Jan 03, 2002 at 11:56:26AM -0500, Greg Ames wrote:
>>
>>>I do see some weirdness in 2.0.30 with www.apache.org/dyn/closer.cgi -
>>>it looks like we're doing one byte reads from the pipe to the cgi. I
>>>don't know yet if 2_0_28 does the same.
Aaron Bannert wrote:
>On Thu, Jan 03, 2002 at 11:56:26AM -0500, Greg Ames wrote:
>
>>I do see some weirdness in 2.0.30 with www.apache.org/dyn/closer.cgi -
>>it looks like we're doing one byte reads from the pipe to the cgi. I
>>don't know yet if 2_0_28 does the same. That's all I've spotted so
On Fri, Jan 04, 2002 at 11:39:27PM -0800, Brian Pane wrote:
> The one-byte reads are for the CGI's response header. The problem is that
> mod_cgi hands off the pipe (non-buffered) to ap_scan_script_header_err(),
> which does single-byte reads until it finds the end of the header. After
> that, m
> On Fri, Jan 04, 2002 at 11:39:27PM -0800, Brian Pane wrote:
> > The one-byte reads are for the CGI's response header. The problem is that
> > mod_cgi hands off the pipe (non-buffered) to ap_scan_script_header_err(),
> > which does single-byte reads until it finds the end of the header. After
>
> > On Fri, Jan 04, 2002 at 11:39:27PM -0800, Brian Pane wrote:
> > > The one-byte reads are for the CGI's response header. The problem is that
> > > mod_cgi hands off the pipe (non-buffered) to ap_scan_script_header_err(),
> > > which does single-byte reads until it finds the end of the header.
21 matches
Mail list logo
