 |
 |
On Sun, 9 Oct 2011, Matevz Tadel wrote: >>> In our experience, without the very detailed I/O monitoring, we: >>> 1) Don't get any monitoring for a client that crashes (disconnects without >>> a >>> close). >> That information can be put in the summary record, if need be. I say need >> be >> because it's a relatively rare event (yes, it does happen in spurts). > > There could be a separate "close on disconnect" trace type that is sent in > this case and includes all the information usually associated with close. Sorry, I didn't make myself clear. In the summary record we could supply how many forced close events there were. What you say is along the lines of what I was talking about, indicating whether the close was real or forced. The "manual close" on disconnect is the appropriate action in the collector in any case. >>> 2) Don't get monitoring while a client is running. Example: it's been 5 >>> hours >>> since a job has started; is this because it is getting 1 byte / second, or >>> because the job takes 5 hours and 1 minute? >> some more client input would make things more effecient. > > What do you mean? The the client would also send monitoring information, > either directly to the monitoring host or via the server? I mean the client sending information to he collector through the server. This is the best way of doing it because then you need not configure every single client. > I'd still vote for a single trace entry for a whole vector read. And then > have a new option for full vector read unroll as it really pushes monitoring > overhead to a new level. Now even I have enough ;) Good, I was leaning that way myself. Detailed monitoring is a real bear and you can easily get to the point that the monitoring itself equals (or even exceeds) the data being transferred. Andy