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
