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 process on the production server.
>
> There could be some differences in 2.0.30 due to my test environment: it
> listens on two ports (adds a poll() before the accept() ), and I was
> running thru a firewall which seems to introduce some network errors.
Here's a syscall count printed side-by-side:
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? Perhaps the
rise in writev was to compensate? 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.
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?
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
-aaron
