On 11/4/05, Andrei Dorofeev <[EMAIL PROTECTED]> wrote: > Another approach is to have exacct write final accounting records and > periodically use getacct(2) system call and take live snapshots for > tasks and aggregate them by projects. I've prototyped a tool called > 'taskstat' some > time ago that does exactly that and it works pretty good. Let me know > if you're interested and I'll send you the source for it.
That sounds like a very reasonable way to do it. I hadn't noticed getacct(2) until very recently. It seems as though this approach would work even if interval records are written, so long as taskstat made use of both final and interval records. The only part I don't like about this solution is that I am still writing (and rotating, and deleting) extended accounting records that I really don't want for any reason other than to collect summary data. I think that I could put the code to good use if you were to send it to me. > > It seems as though it should be possible for the kernel to maintain > > per-user, per-project, and per-zone statistics. Perhaps collecting > > them all the time is not desirable, but it seems as though updating > > the three sets of statistics for each context switch would be lighter > > weight than writing accounting records then post processing them. The > > side affect of having this data available would be that tools like > > prstat could report accurate data. Other tools could likely get this > > data through kstat or a similar interface. > > That's going to almost certainly degrade the performance of > benchmarks like kenbus which are running with thousands of > threads and doing a lot of context switching. Have you tried > using DTrace instead? I wrote a script which displays > per-project CPU usage every 10 seconds, and it's very simple > and lightweight. Yeah, that's kinda what I thought. Since the places where I am most concerned about this tend to be 60+ core systems with thousands of processes and threads, I suspect that dtrace for the occasional look may be the best. > #!/usr/sbin/dtrace -s > > #pragma D option quiet Thanks, code carefully tucked away for when I actually get a chance to load test this stuff on S10. > The routine you're looking for is called swtch(). This code is highly > sensitive and adding recent CPU usage to the current thread's project > structure there would probably slow it down enough to be visible > on some benchmarks. The same thing doesn't actually have to be > done for zones. Instead, zone kstats could be updated once per > second by a per-zone thread which could walk all of its projects and > calculate total CPU usage. The per-zone kstats would do the trick for a good number of other workloads I deal with. Since sample periods would be more on the order of many seconds to a couple minutes, updates every second would be just fine. I like this idea - it should be much lighter than mucking with swtch(). This does suggest, however, that there is possibility to do a similar trick by walking the process list every second (or other configurable period...) and performing per user, (per task?), per project, and per zone kstat updates. A hook would probably need to be added to exit as well. It seems as though this would make it so that the type of summary data that taskstat was written to collect could easily be intergrated into prstat by observing the kstats. Presumably this would mean that prstat -[aTJZ] summary lines would come from kstats instead of iterating over the active processes (and missing out on the ones that died). > > - Andrei > Mike _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
