Justin Erenkrantz wrote: >Well, first off, here are some kdumps on this: > >http://www.apache.org/~jerenkrantz/freebsd/ > >ktrace.dump.abs.gz - kdump'd output with absolute timestamps >ktrace.dump.rel.gz - kdump'd output with relative timestamps >ktrace.out.gz - raw ktrace file >
Can you clarify what it is that these traces are supposed to show? Was there a spike in load during the middle of the test case that the traces represent? Or for the entire duration of the test? Or none of it at all? I can't find any clear evidence of a spike in syscalls/second (to match what happened on daedalus) anywhere in the trace data. There's an interesting interval from 1010550089.424071 to 1010550089.550825 when no system calls complete (there are some reads and at least one stat that run for a long time during that interval), but the net result of that is a drop in syscalls/second, not an increase. Thus I'm not sure if this is related to the problem, unless the phenomenon on daedalus happens when a whole lot of syscalls get blocked for some reason and then all unblock at once. It looks like you used flood to hit the server with a lot of requests in parallel, right?. If so, can you recreate the problem with a test case that issues just one request at a time? >One thing I noticed is that shutdown(2) looks very expensive. > From the traces, the elapsed time for shutdown calls in general appears to be somewhat smaller than that of open or stat calls. Are there specific slow shutdown calls that you're looking at (ones that are much more expensive than the average)? --Brian P.S.: Not one brk call in the entire trace...does that surprise anybody else?
