httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: 2.0.30-dev load spiking [was: upgrade to FreeBSD 4.5-PRERELEASE]
Date Thu, 03 Jan 2002 17:22:44 GMT
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.28                        2.0.30
> 
> 1696 sendfile                 1180 gettimeofday
>  920 select                   805 read
>  355 open                     579 open
>  322 gettimeofday             577 fcntl
>  314 read                     359 close
>  287 lstat                    260 getrusage
>  199 stat                     232 stat
>  133 close                    206 select
>  114 getrusage                156 writev
>  109 fstat                    134 setsockopt
>  102 write                    134 poll
>  100 getdirentrie             134 getsockname
>   72 fcntl                    134 accept
>   55 writev                   130 write
>   50 lseek                    129 fstat
>   50 fstatfs                  127 shutdown
>   11 shutdown                 113 lstat
>   11 setsockopt               80 munmap
>   11 getsockname              80 mmap
>   11 accept                   72 getdirentries
>    8 munmap                   36 lseek
>    8 mmap                     36 fstatfs
>                               18 sendfile
>                               11 SIGNAL
>                                3 pipe
>                                3 break
>                                1 wait4
>                                1 fork
> 
> At first the sendfile difference jumped out at me, perhaps we're doing
> something different in how we decide when to use sendfile? 

well, I think that's something wrong with my log replay setup.  It looks
like sendfile sends the first chunk of data, then I loose the connection
(ergo far fewer sendfile calls) and we get SIGPIPE.  

> Granted, this is not at all under
> the same workload, but I'm assuming that at least one of the load spikes
> was captured in the 2.0.30 trace.

It's just log replay, hoping I might trigger the bad behavior without
having to bounce the live server again.

> 
> The other thing that jumps out at me is the existance of 11 SIGNALS
> in the 2.0.30 trace. How often would we expect SIGNAL to occur under
> normal conditions?

SIGPIPE on network connections mostly; could be my firewall.  You see
that a fair amount live, but not at all in the 2_0_28 truss.

> Also, this is not normalized, but the total syscall count for each is
> not that far off:
> 
> aaron@daedalus% wc -l ~gregames/2.0.30.truss ~gregames/2_0_28.truss           ~
>     5731 /home/gregames/2.0.30.truss
>     4938 /home/gregames/2_0_28.truss

That was me looking at the size of the file as I was running log
replay.  I quit when they were close to the same.

As I mentioned in another post, it looks like there's something very
funky going on with reads from a cgi pipe.  Look for
www.apache.org/dyn/closer.cgi in the 2.0.30 truss.

Greg

Mime
View raw message