Re: [zones-discuss] zonestat, prstat -Z, and cpu accounting
Peter Tribble wrote: On Tue, Jul 27, 2010 at 5:34 PM, Steve Lawrence stephen.lawre...@oracle.com wrote: Now, if you want to account for cpu utilization by children, why not use the pr_ctime member of the psinfo structure? As far as I understand it, that collects cpu for child processes that exit, so why can't that be used instead of monkeying about with extended accounting? What am I overlooking here? I haven't explored an algorithm for tracking that. At some point, the child is running, in which case I may have added its current usage to the zone's usage. When the children exit later, I would need to figure out the parent the usage was added to so I can avoid double counting usage I've already charged to the zone. Well, no, you just create the process tree and walk down it from the top. Some might worry about missing data from a child that exits while you're doing the measurement; I tend not to worry too much, because you'll catch it on the next interval in any event. I'm more worried about double counting. For instance, if I count a proc, and then it exits, and I then count its parent's child usage, I will count the processes's usage twice. I don't think that /proc guarantees to report all parents before all children when doing readdir(). I would need to investigate that further. The other bit to solve would be zone-entered processes, which will have a parent in the global zone. The usage by thein-the-zone children would bubble up to a parent in the global zone. This would certainly be wrong. Well, how common are zone-entered processes? And how should they be accounted for anyway? (What sort of examples do we have?) Anything that is zlogin'ed into the zone. Admin's can zlogin anything they want into a zone, and that usage should be counted towards the zone's usage. Thanks! ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] zonestat, prstat -Z, and cpu accounting
Looking at the recent zonestat arc case reminded me of something I've been meaning to ask for a while. In the case, it says: prstat polls /proc, and will not account for cpu used by short-lived processes. and Extended accounting must be used to compute the cpu utilization because it will contain all data associated with processes which have exited. And this is something that's been discussed before. Now, if you want to account for cpu utilization by children, why not use the pr_ctime member of the psinfo structure? As far as I understand it, that collects cpu for child processes that exit, so why can't that be used instead of monkeying about with extended accounting? What am I overlooking here? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonestat, prstat -Z, and cpu accounting
Peter Tribble wrote: Looking at the recent zonestat arc case reminded me of something I've been meaning to ask for a while. In the case, it says: prstat polls /proc, and will not account for cpu used by short-lived processes. and Extended accounting must be used to compute the cpu utilization because it will contain all data associated with processes which have exited. And this is something that's been discussed before. Now, if you want to account for cpu utilization by children, why not use the pr_ctime member of the psinfo structure? As far as I understand it, that collects cpu for child processes that exit, so why can't that be used instead of monkeying about with extended accounting? What am I overlooking here? I haven't explored an algorithm for tracking that. At some point, the child is running, in which case I may have added its current usage to the zone's usage. When the children exit later, I would need to figure out the parent the usage was added to so I can avoid double counting usage I've already charged to the zone. The other bit to solve would be zone-entered processes, which will have a parent in the global zone. The usage by thein-the-zone children would bubble up to a parent in the global zone. This would certainly be wrong. -Steve ___ zones-discuss mailing list zones-discuss@opensolaris.org
