dtrace discuss - Mar 2008 - Replace vmstat & iostat by dtrace commands in solaris 10

Hi
In solaris 9 I used to use vmstat command to detect any cpu and memory
performance problems by checking values for the following vmstat command
outputs:
		r of  kthr : Number of threads in run queue : 
		id of cpu : Percentage usage of CPU time spent in idle
time: 
		sr of  memory : Memory page activity (Number of pages
scaned): 

I also use iostat -xn command to detect performance problems with diks
or metadevices by checking values for the following "iostat -xn"
command
outputs

		%w: The percentage of time there are transactions
waiting for service..
		wsvc_t: average service time in wait  queue,in
milliseconds. Time spent by a transaction in queue. 

As I heard that such commands may disturb the running system if they are
run periodically  through crontab jobs 

Could you please tell me if there are equivalent commands in solaris 10
using dtrace that can be used to identify performance problems cpu,
memory and disks

Thanks

Riadh YOUNSI
Alcatel-Lucent

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080309/158ed1d8/attachment.html>

On Sun, Mar 9, 2008 at 1:09 PM, YOUNSI RIADH
<Riadh.Younsi at alcatel-lucent.fr> wrote:
> As I heard that such commands may disturb the running system if they are
run
> periodically  through crontab jobs
The process of running any cron job (even if it is "echo cron is still
alive") likely has more overhead with it than having vmstat look at
the various kstat values.  If you have hundreds or thousands of disks,
iostat may chew up a few cycles, but any system with such a large
number of disks is likely to have enough CPU power that it is rather
insignificant in the grand scheme of things.  There is likely more to
be gained in disabling per partition kstats (see sd(7D) and ssd(7D))
than there is in limiting use of vmstat or iostat.

If you were asking about prstat or top, I would argue that they are
both rather heavy commands and should be avoided except for when you
need them.
> Could you please tell me if there are equivalent commands in solaris 10
> using dtrace that can be used to identify performance problems cpu, memory
> and disks
Any dtrace command would either be duplicating effort that is done
already when updating kstat data or would be simply reading the same
kstat data read by vmstat and iostat.  vmstat and iostat are already
written and well tested.  Use them.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/

At 16:10 -0600 3/9/08, Mike Gerdts wrote:
> vmstat and iostat are already written and well tested.
> Use them.
I think this is good counsel, as long as the "written
and well tested" tools give you the needed information
in a form that can parsed reliably, etc.


If not, it is quite possible to convince DTrace to do
long-term logging without incurring the overhead of a
new process starting for each set of samples.

Basically, this involves running a process which runs
dtrace(8) and writes the output to a log file.  The
process blocks when no input is available, so no cron
or other explicit scheduling is needed.

Of course, there are some complications.  For example,
DTrace isn''t equipped with string-handling facilities,
so it can be hard to generate output that can be parsed
reliably.  Also, if the vendor allows an application to
turn off tracing, any logging attempt will suffer.

If you would like to know more about this approach, see
http://www.cfcl.com/DT_Logger, my configurable logging
suite, based on DTrace and intended for "set and forget"
operation.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

Rich Morin wrote:
>
> Of course, there are some complications.  For example,
> DTrace isn''t equipped with string-handling facilities,
> so it can be hard to generate output that can be parsed
> reliably.
>   
Unless I''m misunderstanding what you mean here (a real possibility), 
DTrace has plenty of string handling capability in the form of real 
string variables (as opposed to C''s character arrays), "str*"
functions,
and a fully functional printf action.  After you turn on "option
quiet",
there should be no format you can''t generate.

The only real issues with output in DTrace is records with a variable 
number of items in the output, due to the fixed length record coming 
from the probe''s action statements.  There are ways to get around that,
but it can get intense if the "variability" is extreme.

Chip

At 19:17 -0500 3/9/08, Chip Bennett wrote:
> Rich Morin wrote:
>>
>> Of course, there are some complications.  For example,
>> DTrace isn''t equipped with string-handling facilities,
>> so it can be hard to generate output that can be parsed
>> reliably.
>>
>
> Unless I''m misunderstanding what you mean here (a real
> possibility), DTrace has plenty of string handling
> capability in the form of real string variables (as
> opposed to C''s character arrays), "str*" functions,
> and a fully functional printf action. ...
Well, I''d be delighted to learn some new DTrace tricks;
please let me know if I''m missing anything...

When I looked into generating YAML (http://www.yaml.org)
from probes, I was stymied by the problem of "escaping"
the inevitable oddball characters that might show up in
string values.  IIRC, C strings can contain anything but
zeroes, but control characters, quotes, and such aren''t
going to pass smoothly through a typical YAML parser.

Languages such as Perl and Ruby have all sorts of string
manipulation tools that will let me do percent-encoding,
etc.  However, I don''t see any equivalent functionality
in DTrace.  Also, there is an argument to be made that I
shouldn''t do (expensive) string operations in probes.

-r


P.S.  My workaround was to use counted strings, as:

  #               0
  #      123456789 12345

  cwd=15''Idiot''s delight''

Because DTrace will tell me the length of an arbitrary
string, I can easily print something like this:

  printf("cwd=%d''%s''\n", len, cwd)

The parsing code has to handle embedded newlines in an
incoming text string, but the count tells it what it
needs to know (and the closing quote allows a bit of
sanity checking).
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

On Sun, Mar 09, 2008 at 08:09:56PM +0100, YOUNSI RIADH
wrote:
> Hi
> In solaris 9 I used to use vmstat command to detect any cpu and memory
> performance problems by checking values for the following vmstat command
> outputs:
> 		r of  kthr : Number of threads in run queue : 
> 		id of cpu : Percentage usage of CPU time spent in idle
> time: 
> 		sr of  memory : Memory page activity (Number of pages
> scaned): 
> 
> I also use iostat -xn command to detect performance problems with diks
> or metadevices by checking values for the following "iostat -xn"
command
> outputs
> 
> 		%w: The percentage of time there are transactions
> waiting for service..
> 		wsvc_t: average service time in wait  queue,in
> milliseconds. Time spent by a transaction in queue. 
> 
> As I heard that such commands may disturb the running system if they are
> run periodically  through crontab jobs 
> 
> Could you please tell me if there are equivalent commands in solaris 10
> using dtrace that can be used to identify performance problems cpu,
> memory and disks
There are still vmstat, prstat etc in Solaris 10. And despite the
existence of DTrace in S 10 they are still _very_ usefull. Usually
if you are hunting for performance problems you still start with them
to narrow the area where they (problems) might exists.

There is however more :-). Just for start:
http://przemol.blogspot.com/2007/10/sunsolve-deeper-look-into-vmstat.html

Regards
przemol

-- 
http://przemol.blogspot.com/





















----------------------------------------------------------------------
Asy i Cieniasy pilkarskiej ekstraklasy
kliknij >> http://link.interia.pl/f1d27