Hi everybody! I need to write a script that shows cpu consumption by zones. The output should be something like this: ZONE USR SYS IDLE global x x x zone1 x x x I''ve read the documentation and I''ve found probes like ''cpu_ticks_user'' from sysinfo provider. Unfortunately these probes don''t exist anymore. How can I obtain this result? Thanks! -- This message posted from opensolaris.org
Davide Vanoni wrote:> Hi everybody! I need to write a script that shows cpu consumption by zones. The output should be something like this: > ZONE USR SYS IDLE > global x x x > zone1 x x x > > I''ve read the documentation and I''ve found probes like ''cpu_ticks_user'' from sysinfo provider. Unfortunately these probes don''t exist anymore. > How can I obtain this result? > Thanks! >Are you aware of prstat -Z ? Not quite the same, but maybe it gives you what you need? -- Andrew
Andrew wrote:>Are you aware of prstat -Z ? >Not quite the same, but maybe it gives you what you need? >Thanks for your reply! Unfortunately prstat ignores anything that happened between samples. I need something that maintains information about cpu utilization between samples (for short-lived processes). The problem is to take precisely this kind of information by zones. Maybe it is possible to do it with dtrace but I don''t know how. Thanks for your suggestions! -- This message posted from opensolaris.org
It is definitely possible to do so with DTrace by capturing events when threads goes on/off cpu then record the data onto an aggregate indexed by zonename. IIRC, prstat uses microstate by default as of S10 so it is not sampling. Depending on what you are doing, you might want to look at acct(1M). On Wed, Nov 12, 2008 at 4:32 PM, Davide Vanoni <davide.vanoni at gmail.com> wrote:> Andrew wrote: >>Are you aware of prstat -Z ? >>Not quite the same, but maybe it gives you what you need? >> > Thanks for your reply! Unfortunately prstat ignores anything that happened between samples. I need something that maintains information about cpu utilization between samples (for short-lived processes). The problem is to take precisely this kind of information by zones. Maybe it is possible to do it with dtrace but I don''t know how. Thanks for your suggestions! > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >-- Just me, Wire ... Blog: <prstat.blogspot.com>
Wee Yeh Tan wrote:> It is definitely possible to do so with DTrace by capturing events > when threads goes on/off cpu then record the data onto an aggregate > indexed by zonename. > > IIRC, prstat uses microstate by default as of S10 so it is not sampling.But it iterates thru /proc at some sample rate, so it will miss short lived processes.> > Depending on what you are doing, you might want to look at acct(1M). > > On Wed, Nov 12, 2008 at 4:32 PM, Davide Vanoni <davide.vanoni at gmail.com> wrote: >> Andrew wrote: >>> Are you aware of prstat -Z ? >>> Not quite the same, but maybe it gives you what you need? >>> >> Thanks for your reply! Unfortunately prstat ignores anything that happened between samples. I need something that maintains information about cpu utilization between samples (for short-lived processes). The problem is to take precisely this kind of information by zones. Maybe it is possible to do it with dtrace but I don''t know how. Thanks for your suggestions! >> -- >> This message posted from opensolaris.org >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> > > >-- ----------------------------------------------------------------------- ______ Joseph Balenzano /_____/\ ISV Engineering /____ \\ \ Sun Microsystems Inc. /_____\ \\ / joseph.balenzano at sun.com /_____/ \/ / / Phone/Fax 203.653.4186 /_____/ / \//\ \_____\//\ / / \_____/ / /\ / \_____/ \\ \ \_____\ \\ \_____\/ ----------------------------------------------------------------------
On Wed, Nov 12, 2008 at 11:48 PM, Joseph Balenzano <Joseph.Balenzano at sun.com> wrote:> But it iterates thru /proc at some sample rate, so it will miss short lived > processes.Ahh.. that was the original poster''s concerns... I somehow missed that. Thanks for the correction. -- Just me, Wire ... Blog: <prstat.blogspot.com>
On Wed, Nov 12, 2008 at 2:32 AM, Davide Vanoni <davide.vanoni at gmail.com> wrote:> Andrew wrote: >>Are you aware of prstat -Z ? >>Not quite the same, but maybe it gives you what you need? >> > Thanks for your reply! Unfortunately prstat ignores anything that > happened between samples. I need something that maintains > information about cpu utilization between samples (for short-lived > processes). The problem is to take precisely this kind of > information by zones. Maybe it is possible to do it with dtrace but > I don''t know how. Thanks for your suggestions!With a bit of scripting you can get this data from extended (task) accounting. I have been using this method for a couple years with great success. Unfortunately I can''t share the code. :( Some good starting points to understand how to do this are: http://perfcap.blogspot.com/2005/04/writing-accounting-records-at-time.html http://perfcap.blogspot.com/2005/04/sequencing-exacct-logs.html http://perfcap.blogspot.com/2005/04/automated-rotating-exdump.html http://perfcap.blogspot.com/2005/07/extracct-code-posted-on-orcawarecom.html I probably missed a couple as well - you may want to take a closer look Adrian''s 2005 postings to catch the rest. I haven''t tried out extracct, as I already had my Perl version that uses the Sun::Solaris::Exacct Perl module. If you need to create your own tool, you can certainly do so in C or Perl. I started a discussion of perhaps a better way to collect the data at http://mail.opensolaris.org/pipermail/perf-discuss/2005-November/002048.html. Essentially, this mechanism would give you the number of CPU ticks used on a per user, project, and zone basis through kstat or similar. However, this would involve kernel changes. One of these days I hope to find the time to prototype this to understand the performance implications. If done right, it should be about the same overhead as having a single instance of prstat running. -- Mike Gerdts http://mgerdts.blogspot.com/