Brian Pane wrote: > > Can someone describe what the difference is between the select/accept/mutex > behavior of .28 and .29/.30 on daedalus?
There shouldn't be any differences theoretically, and I haven't found any accidental ones yet either. However there were changes in that time period which moved the client socket out of the conn_rec. This changed things like the mechanism to set read timeouts, and lingering close. The resulting syscalls _should_ be identical AFAIK. I was considering creating a build from a date checkout prior to when these changes started. But that was the same day 2_0_28 was rolled (Nov 12), so it wouldn't prove a whole lot if it worked. > Also, do we have any data on syscalls per request during the spikes? > Based on Greg's vmstat data showing a spike in syscalls/second concurrent > with the spike in load, I'd > expect that either: > * The number of requests/second increased, or > * The number of syscalls/request increased That's a very interesting question. I wish I could give you a good answer. Is there some function that returns the total number of syscalls a process has done? If so, we could create a patch to log the delta in the number of syscalls at the end of each request, like I'm doing for cpu ticks now. btw, if the connection dies during ap_read_request, the request isn't logged, and my current patch will loose any cpu time burned during the reading and error processing. Greg
