 |
 |
Hi Brian, This should be posted as a bug. There are a number of issues: 1) Some modes of sending data are not counted in the file statistics, notably when sendfile() is used. 2) Readv requests are not included in the detailed monitoring record. The latter one raises a couple of questions: a) Does each read segment create a monitor record entry? This could cause excessive number of entries as readv vectors can get quite long. On the other hand, the alternate read mechanism would simply issue multiple reads and all of these would have been put in the monitor record. So, it may be moot. b) You mention a separate entry for readv. Is this a tag on the entry? A separate code? We can do this since readv requests were never logged in the first place so no compatability problems. c) Should readv capture be configurable? Doesn't seem like that is useful. Once you post this as a bug, I will add his to your post. Andy On Fri, 7 Oct 2011, Brian Bockelman wrote: > Hi folks, > > It appears there are quite a few missing bytes in the detailed xrootd statistics. When comparing the number of bytes sent in the sum of all read/write request entries with the total number of bytes in the close request entries, things are off by a factor of 100 (or more) for CMS jobs. > > Perhaps not coincidentally, vector read calls are over 99% of the bytes moved by CMS. Is it possible that they are not getting accounted for? > > Brian > > PS - for what it's worth, it would be nice if ReadV's could be monitored separately; this allows me to monitor for badly behaving jobs. >