Bharat Banate's Work Profile

View Bharat Banate's profile on LinkedIn
Showing posts with label Sun OS. Show all posts
Showing posts with label Sun OS. Show all posts

Monday, September 10, 2007

SUN OS:DTrace Continue

In the preceding examples, you learned to use two simple probes named BEGIN and END. But where did these probes come from? DTrace probes come from a set of kernel modules called providers, each of which performs a particular kind of instrumentation to create probes. When you use DTrace, each provider is given an opportunity to publish the probes it can provide to the DTrace framework. You can then enable and bind your tracing actions to any of the probes that have been published. To list all of the available probes on your system, type the command:

# dtrace -l
ID PROVIDER MODULE FUNCTION NAME
1 dtrace BEGIN
2 dtrace END
3 dtrace ERROR
4 lockstat genunix mutex_enter adaptive-acquire
5 lockstat genunix mutex_enter adaptive-block
6 lockstat genunix mutex_enter adaptive-spin
7 lockstat genunix mutex_exit adaptive-release

... many lines of output omitted ...

#

It might take some time to display all of the output. To count up all
your probes, you can type the command:

# dtrace -l | wc -l
30122

You might observe a different total on your machine, as the number of probes varies depending on your operating platform and the software you have installed. As you can see, there are a very large number of probes available to you so you can peer into every previously dark corner of the system. In fact, even this output isn't the complete list because, as you'll see later, some providers offer the ability to create new probes on-the-fly based on your tracing requests, making the actual number of DTrace probes virtually unlimited.

Now look back at the output from dtrace -l in your terminal window. Notice that each probe has the two names we mentioned earlier, an integer ID and a human-readable name. The human readable name is composed of four parts, shown as separate columns in the dtrace output. The four parts of a probe name are:


Provider

The name of the DTrace provider that is publishing this probe. The provider name typically corresponds to the name of the DTrace kernel module that performs the instrumentation to enable the probe.

Module

If this probe corresponds to a specific program location, the name of the module in which the probe is located. This name is either the name of a kernel module or the name of a user library.

Function

If this probe corresponds to a specific program location, the name of the program function in which the probe is located.

Name

The final component of the probe name is a name that gives you some idea of the probe's semantic meaning, such as BEGIN or END.

When writing out the full human-readable name of a probe, write all four parts of the name separated by colons like this:

provider:module:function:name





Saturday, September 8, 2007

SUN OS:D-Trace:Getting Started

DTrace helps you understand a software system by enabling you to dynamically modify the operating system kernel and user processes to record additional data that you specify at locations of interest, called probes. A probe is a location or activity to which DTrace can bind a request to perform a set of actions, like recording a stack trace, a timestamp, or the argument to a function. Probes are like programmable sensors scattered all over your Solaris system in interesting places. If you want to figure out what's going on, you use DTrace to program the appropriate sensors to record the information that is of interest to you. Then, as each probe fires, DTrace gathers the data from your probes and reports it back to you. If you don't specify any actions for a probe, DTrace will just take note of each time the probe fires.

Every probe in DTrace has two names: a unique integer ID and a human-readable string name. We're going to start learning DTrace by building some very simple requests using the probe named BEGIN, which fires once each time you start a new tracing request. You can use the dtrace(1M) utility's -n option to enable a probe using its string name. Type the following command:

# dtrace -n BEGIN

After a brief pause, you will see DTrace tell you that one probe was
enabled and you will see a line of output indicating that the BEGIN probe fired. Once you see this output, dtrace
remains paused waiting for other probes to fire. Since you haven't enabled
any other probes and BEGIN only fires once, press Control-C

in your shell to exit dtrace and return to your shell prompt:

# dtrace -n BEGIN -n END
dtrace: description 'BEGIN' matched 1 probe
dtrace: description 'END' matched 1 probe
CPU ID FUNCTION:NAME
0 1 :BEGIN
^C
0 2 :END
#

As you can see, pressing Control-C to exit dtrace
triggers the END probe. dtrace reports
this probe firing before exiting.

Now that you understand a little bit about naming and enabling probes,
you're ready to write the DTrace version of everyone's first program, “Hello,
World.” In addition to constructing DTrace experiments on the command
line, you can also write them in text files using the D programming language.
In a text editor, create a new file called hello.d and
type in your first D program:

Example 1–1 hello.d: Hello, World from the D Programming Language

BEGIN
{
trace("hello, world");
exit(0);
}
After you have saved your program, you can run it using the dtrace -s option.
Type the following command:

# dtrace -s hello.d
dtrace: script 'hello.d' matched 1 probe
CPU ID FUNCTION:NAME
0 1 :BEGIN hello, world
#

Wednesday, September 5, 2007

SUN OS:DTrace Utility

DTrace,a very intresting concept or you can say that utility avilable in SUN Solraris.
As a software developer you always trace your programme for finding bugs.
Similar thing but in differnt way you can tarce your files,command in SUN OS.
That is called D-Trace.In this type your command and also give DTrace to it,you can see
that how your commmand works.

Technically speaking

DTrace is a comprehensive dynamic tracing framework for the Solaris Operating Environment.
DTrace provides a powerful infrastructure to permit administrators, developers,
and service personnel to concisely answer arbitrary questions about the behavior
of the operating system and user programs.

SUN OS:Introduction

Sun Solaris also known as SunOS or Sun is the name of the Sun company's Unix variant operating system that was originally installed on SPARC computers. It is sold together with the OPENLOOK user interface OpenWindows. This bundle is known as Solaris. SunOS 4.1.x (as part of Solaris 1.x) is a BSD Unix system, and supports multiprocessing, but not yet multithreading. Further development of Solaris 1 was discontinued at the end of 1998. In parallel to Solaris 1.x, Sun has launched a Version 2.x on the market. This is an implementation of System V. Beginning with Version 2.2 it also supports multithreading, that is to say, the distribution of threads among various processors. The allocation of the processors is done automatically, so that the user does not have to be involved. From Solaris Version 2.5 onward, 64-bit processors and the use of Ultra-Creator graphics for 2-D and 3-D applications are supported.