System and method for performing monitoring of resources in a data processing system in real time5463775Abstract A graphical system resource monitor is provided to depict, in real-time, a data processing system's internal resource utilization. A window or viewport of a data processing system displays user specified internal system resources, such as memory, CPU, or peripheral device availability/utilization. This graphical representation of the `state` of the data processing system's resources is maintained in real-time, while the impact on the system's performance in providing such information is kept to a minimum. This is accomplished through a combination of various techniques, including specialized device drivers for the respective devices coupled with a unique data reduction technique. The graphical results of these resource monitors are continually updated in real-time. This real-time support provides an immediate and accurate representation of the internal operations of the data processing system. Further, these resources can monitored at the process level of a multiprocessing system. These representations can be used by a user to identify, isolate, and fine-tune the data processing system's resources to improve the overall efficiency of the system being monitored. Claims We claim: Description A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
TABLE 1
______________________________________
RAM Monitor Scenario Interpretation
Scenario Interpretation
______________________________________
A large application
The loaded program is
is loaded. The
reported as part of
working set shows a
the working set, and its
a big increase. The
fixed memory is reported as
fixed memory shows a
part of the system fixed
small increase. The
memory (also included in
user decides not to
the working set). For 60
use the application
seconds the memory used
for a while, and a
loading the program continues
minute later the
to be reported in the working
working set drops back
set.
down.
Because the application is
not active during the 60
seconds (and therefore most
of the application's memory
is not accessed), the working
set drops back down after a
minute even though the
program is still loaded. The
application's fixed memory,
however, is still reported as
part of the working set and
as part of fixed memory.
A large application is
This application probably
loaded. The working
uses more memory than it will
set shows a bigger
during normal operation. The
increase than expected.
reported working set may drop
later during normal opera-
tion.
A large application is
When OS/2 unloads the
loaded but then
application, OS/2 frees the
immediately ended.
application's memory. Freed
The reported working
memory is not reported in
set rises and falls
working set.
quickly.
The swap-in and
When new segments must be
swap-out graphs show
swapped in or loaded, old
quite a bit of
segments that have not been
activity, even though
accessed recently may need to
the working set is not
be swapped out or discarded.
100% The memory swapped out was
reported in the working set
if it was last accessed more
than 60 seconds ago.
Even with occasional swap
activity, there may still be.
enough memory for good
performance. More physical
memory is not necessarily
needed.
When the OS/2 system
The fixed memory may include
and the SPN a large VDISK or DISKCACHE as
application first
as defined in the CONFIG.SYS
start, fixed memory is
file.
higher than anticipated.
For a stable scenario,
The working set is lower
the working set period
because less memory is
is changed from 60
typically accessed in 10
seconds to 10 seconds.
seconds than in 60.
The reported working
set is now lower.
For a stable scenario,
The working set is higher
the working set period
because more memory for more
is changed from 60
applications is typically
seconds to 1000
accessed in 1000 seconds than
seconds. The reported
in 60 seconds.
working set is now
higher.
______________________________________
Note:
The Working Set Period is set to 60 seconds for all scenarios.
This information on memory utilization, especially the Working Set Memory, is useful for showing if the physical memory in the computer is sufficient for the currently active applications. This technique further allows a user to ask `what if?` questions without actually resetting the parameters that affect the variable or entity in question. In summary, this technique quickly calculates the Random Access Memory (RAM) utilization for an operating system as a whole, including the Working Set, Fixed, and Used amounts of RAM and displays these results graphically. DYNAMIC MONITORING The procedure for allowing a data processing system user to vary parameters that affect the display of dynamic monitors on a display screen will now be described. This procedure concerns the control of dynamic monitoring of a time-related function on a data processing system display when the function is affected by at least one variable. The data being monitored varies depending upon how certain parameters are set. As shown in FIG. 7b, a dialogue box is presented to a user on the display screen, which the user has selected from the window's menu or action bar 110 as shown in FIG. 7a. This dialogue box 120 contains fields 122 in which the user can enter new values of the parameters. After the user types in new, or modified, parameters, the program dynamically modifies the underlying function to use the new parameter's value. This is accomplished via an API call by the program controlling the dialogue box to the program controlling the data collection. As shown in FIG. 8, a user parameter is queried at 112 via a dialogue box on the screen of FIG. 7b. A check is made at 114 to determine if the parameter is valid. If not valid, an error message is displayed at 116 and the user parameter is again queried at 112. If valid, the new parameter is sent via a named pipe (29 of FIG. 1) to the Data Collection Facility API at 118. The Data Collection Facility accepts data and changes the parameter of the specified function at 119. Although the preferred embodiment uses a dialogue box, other types of controls could similarly be used to obtain new parameters from a user, such as scroll bars, spin buttons, entry fields or command line parameters. This method for varying parameters is used to modify the above-described RAM Working Set Period, the parameter which affects the dynamic display of the RAM Working Set Memory on the RAM Monitor window. As was previously discussed, the RAM Working Set Memory usually becomes lower when the user selects a lower RAM Working Set Period, and higher when selects a higher RAM Working Set Period. PERIPHERAL DEVICE UTILIZATION The general technique used for determining device utilization does not require high-resolution timing or changes to the hardware and/or operating system. Rather, this method periodically samples the device's status and records the number of times that the device returns a `device busy` status. The technique used for generating the periodic rate can vary from implementation to implementation, and is not specific or critical to understanding the underlying device utilization measurement technique. For example, on a personal computer it is convenient to use the hardware timer interrupt, which occurs every 32 milliseconds on an IBM Personal Computer running OS/2, and every 55 milliseconds when running DOS. Further, the technique used to query device status will vary from device to device, but is similarly extendable to other types of devices without departing from the spirit and scope of the present invention. For example, an IBM Personal Computer ESDI disk drive provides continuous status at input port address x`3512` (hex). Other devices require that a device query command be sent to the device before before the device returns status information. Referring now to FIG. 9, the collection program 140, which is a device driver in the preferred embodiment, receives interrupts 142 from a hardware timer 144. Each timer `tic` causes the poll count to be incremented at 146. Then, the device 148 being measured is queried at 152, through its associated device controller 150 to determine if the device 148 is busy or not. This busy information is reported at 154 by the device controller 150. A check is made at 156 to see if the device reported a busy status. If so, the Busy Count is incremented at 158, and the collection ends until triggered again by a tic 142. Once the collection program has a sufficient number of samples, as determined by the user specified or default parameters, the reporting program 162 then gathers the busy and total counts at 164, and calculates device utilization at 166 by dividing the busy count by the total count. This calculation is shown as follows: Device Utilization=Busy Count/Total Count This utilization number can then be reported by any number of methods, such as written to the display at 168 in either numeric or graphical form as hereinafter described, or written to a log file. This report program periodically invokes the collection program device driver, and plots the ratio of the number of busy tics to the total number of tics 142 as a ratio, in the preferred embodiment. The device driver is invoked every one second to recalculate the device utilization, although the frequency of this invocation is user-defined and modifiable by the procedures described elsewhere in this preferred embodiment description. Because device utilization is being estimated by sampling, rather than measured directly, there is potential for error in the estimate. Statistical methods can predict this potential error. As will be readily understood by those of skill in the art, the sampling technique above uses repeated samples that have only two possible values, busy or not busy. Such samples are called Bernouli samples, and follow the Binomial Distribution. Further, if the number of samples is relatively large, say greater than 20, then the Binomial Distribution may be approximated by the Normal Distribution. For the Normal Distribution, the error in the sample percentage as compared to the actual percentage is less than: Error=Z(a/2)*(x/n*(1-x/n)/n)**1/2 where: a=Desired confidence level(typically 0.95 or 0.99) Z=Standard random variable for Normal Distribution x=`Successful` number of samples (in this case, busy samples) n=Total number of samples The value for Z(a/2) is found in statistical tables. For a 95% confidence, Z(a/2) equals 1.960. For a 99% confidence Z(a/2) equals 2.576. As a specific example, consider that on an IBM Personal Computer running OS/2 a total of 10*1/.032=312 samples can be collected in 10 seconds. Further, consider that the largest value that the (x/n*(1-x/n)) can attain is 0.25 when the x is exactly one-half of n (This assertion can be proved by elementary calculus). One can then assert with 95% confidence that the maximum error found in a ten second device utilization estimate does not exceed: 1.96*(0.25/312)**1/2=0.055=5.5% A similar calculation would show that the maximum error in a one minute sample would be 2.3%. Thus, statistics show that the device busy sampling method described above does provide good accuracy in estimating device utilization. Further, this method is simpler and less expensive than previous used methods in obtaining device utilization information. An alternative method of measuring peripheral device utilization is as follows. For measuring logical disk activity, file system events, which are generated when processes access the file system via an API, are traced and reduced by the methods described in the device driver section. CPU ACTIVITY CPU activity, or utilization, is measured in the preferred embodiment by starting a process and assigning the process to the lowest priority level in the system. Rather than tracking the amount of work that the process can perform, as was done in the prior art, this invention tracks the amount of time this lowest priority process is executing in the system. Since the process only executes when all other processes at a higher priority have completed their tasks, and no longer need the CPU, the amount of time the system is idle (or available to perform other tasks) is the amount of time the idle process was executing. In the preferred embodiment, data processing system tasks are divided into four classes: (i) Time Critical, which is the highest priority, (ii) Fixed High, which runs before any regular task, (iii) Regular, which is the normal class assigned to application programs, and (iv) Idle, which means don't run if Time Critical, Fixed High, or Regular priority tasks are ready to execute. In the preferred embodiment, the OS/2 RAS Trace Facility, or SYSTRACE, provided by the OS/2 operating system is used to obtain an event trace of this low-level process system activity. This SYSTRACE facility is more fully discussed in the device driver section. Other similar types of system tracing facilities provided by other operating systems could be used in a similar manner to provide this utility, and not depart from the spirit and scope of the present invention. The following describes the specific SYSTRACE utilization. DEVICE DRIVER In the preferred embodiment, a device driver has been written to perform the following SYSTRACE utility. The device driver is installed in the normal way, being identified in the CONFIG.SYS file which the data processing system reads upon Initial Program Load(IPL). Special groups of instructions, called hooks, are included at key points in system and application programs in order to track execution flow. Each hook has a unique identity (Major code and Minor code) distinguishing it from all other hooks, and may or may not include key program variables, symbols, or return codes as data items. In the preferred embodiment of OS/2, there exists a facility known as SYSTRACE which provides means for hooks to be generated, collected, and stored in a buffer. Other operating systems provide similarly functionality through their own system utilities, and this utility can be considered as a generic tool for managing hooks. The device driver intercepts all hooks passing through SYSTRACE, filters out undesired hooks or information contained therein, and passes only the precise hooks and information desired by the control program. The device driver and control program are the two elements comprising the previously discussed Data Collection Facility. Upon device driver installation during system initialization, a 64K buffer is allocated in which data will be formatted and passed to the control program. This buffer is internally divided into two 32K buffers, with a portion of the second buffer being a communications area for use between the device driver and the control program. The communication area is simply a portion of data processing system memory reserved for variables. This memory is accessible by both the device driver and the application program. The following Table 2 defines the variables which occupy the highest (i.e. last) 32 words of the second 32K buffer.
TABLE 2
______________________________________
time.sub.-- int
equ OFFEOH First DD variable uses OFFEO
& OFFE2
varAO equ OFFEOH One of words used on timetag
arithmetic
varA2 equ OFFE2H One of words used on timetag
arithmetic
start.sub.-- time
equ OFFE4H Second DD variable uses
OFFE4 & OFFE6
varBO equ OFFE4H One of words used on timetag
arithmetic
varB2 equ OFFE6H One of words used on timetag
arithmetic
elapsed.sub.-- time
equ OFFE8H Third DD variable uses OFFE8
& OFFEA
var.sub.-- FFE8
equ OFFE8H One of words used on timetag
arithmetic
var.sub.-- FFEA
equ OFFEAH One of words used on timetag
arithmetic
Dekko.sub.-- SEL
equ OFFECH Fourth DD: DEKKO FIRST
OFFEC only 1 word
PID equ OFFEEH Fourth DD: OTHER word for
PID
var.sub.-- FFEC
equ OFFECH One of words used on timetag
arithmetic
var.sub.-- FFEE
equ OFFEEH One of words used on timetag
arithmetic
flush equ OFFOH if 1, flush hook, otherwise
process normally
var.sub.-- FFFO
equ OFFOH One of words used on timetag
arithmetic
switch equ OFFF2H if not 0, switch buffers ==
"flush buffers"
var.sub.-- FFF2
equ OFFF2H One of words used on timetag
arithmetic
reals equ OFFF4H accumulates number of real mode
hooks
var.sub.-- FFF4
equ OFFF4H One of words used on timetag
arithmetic
var.sub.-- FFF6
equ OFFF6H One of words used on timetag
arithmetic
var.sub.-- FFF8
equ OFFF8H One of words used on timetag
arithmetic
int.sub.-- nesting
equ OFFAH keeps up with nesting depth of
interrupts
var.sub.-- FFFA
equ OFFAH one of words used on timetag
arithmetic
current.sub.-- time
equ OFFCH last DD variable uses OFFFC &
OFFFE
oldtime equ OFFCH save previous value
biotime equ OFFEH keep up with high word of time
shortbuf equ O2O2OH approx. 24 bytes effective
buffer size is 08000 - shortbuf
______________________________________
Hooking Also during this device driver install, the device driver saves a copy of the original SYSTRACE code located at the label "strp.sub.-- common" for future use. A call to the OS/2 system routine DevHelp is used to obtain this address, as shown below:
TABLE 3
______________________________________
SAMPLE ASSEMBLY CODE TO OBTAIN THE LOCATION
OF "strp-common"
AX:BX POINTS TO THE VARIABLE
______________________________________
mov a1,10D
mov dl,DevHlp.sub.-- GetDOSVar
call DevHelp
______________________________________
At some later time, the control program executes a "READ" to the device driver at which time the device driver installs a patch (modified code) over a portion of the SYSTRACE kernel code. The patch contains bi-modal (REAL or PROTECT, two differing addressing modes known to those of ordinary skill in the art to be a part of the Intel microprocessor architecture) code which can intercept hooks coming through SYSTRACE in either REAL or PROTECT mode, and filter out those tasks of interest, and perform other tasks, such as event tracing. Unhooking At a still later time, when the system is ready to shutdown, the control program executes a "WRITE" to the device driver, at which time the previously saved SYSTRACE kernel code is restored to its original position in the SYSTRACE facility, thus fully reinstating the original SYSTRACE function. DATA GATHERING Event tracing refers to a process of tracing events as they occur in the data processing system. Time stamps are associated with each event. The events are stored and processed in chronological order. Since the events are chronologically ordered, the events provide the sequence of activities that take place in the data processing system. An example of an event trace is shown in the following Table 4.
TABLE 4
______________________________________
EVENT TRACE EXAMPLE
______________________________________
Time.sub.-- 0 Event.sub.-- 0 data
Time.sub.-- 1 Event.sub.-- 1 data
Time.sub.-- 2 Event.sub.-- 2 data
Time.sub.-- 3 Event.sub.-- 3 data
Time.sub.-- 4 Event.sub.-- 4 data
Time.sub.-- 5 Event.sub.-- 5 data
Time.sub.-- n-1 Event.sub.-- n-1 data
Time.sub.-- n Event.sub.-- n data
______________________________________
The SYSTRACE facility uses the low resolution system clock to place time stamps on events its processes. This is inadequate for the present invention when attempting to analyze performance on system resources. Thus, one of the data processing system's timers is used to determine the delta (difference) times between events and to replace the time in the SYSTRACE records shown above in Table 3 with a high resolution time tag. TIMER The hardware timer of the preferred embodiment is an Intel 8253 timer, which has multiple timers contained within. More detailed information on the 8253 timer can be found in the Intel Manual entitled "Intel Component Data Catalogue", available from the Intel Literature Dept. in Santa Clara, Calif., and hereby incorporated by reference as background material. Timer 0 is programmed to Mode 2. This mode provides a high resolution timer which starts at 0.times.FFFF and counts downward to 0.times.0000 and repeats. The timer function again begins at 0.times.FFFF, or in other words the timer rolls-over. Timer 3 is partially initialized so that the ordinary interrupt generated by other timers on the 8253 timer module are disabled. Ordinarily, when one of the timer/counters counts down to zero, an interrupt is issued so that the system will know that the time being counted has elapsed. In the preferred embodiment of this invention, an interrupt is not desired at the expiration of the timer/counter, and so this is inhibited by partially initializing Timer 3, also known as the watchdog timer (in other possible embodiments, the above timers may be real or they may merely be emulated by software techniques). The actual time interval being counted is approximately 0.8380953445 microseconds per tic. Referring now to FIG. 10, an internal register 180, allocated in system main memory 182 and initialized to 0.times.0000, is incremented each time the interval timer rolls over from 0.times.0000 to 0.times.FFFF. The device driver reads at 170 the value from the internal timer 172 of the timer module 174. This value is then one's-complemented, so that the value effectively ranges from 0.times.0000 to 0.times.FFFF. This complemented timer value 176 is combined with the internal register value 178 to provide a 32 bit timer 180 which can count to approximately one hour before it rolls over. The high order word 178, which is 16 bits, is the internal register rollover counter, and the low order word 176, also 16 bits, is the complemented timer value. This 32 bit value is known as the Time Tag 180, whose use will be described below. In order to maintain timing integrity, the above described internal timer must be read at least once every 55 milliseconds, in order to not miss a rollover. Activating SYSTRACE Major Code 04 will suffice for this requirement. Major Code 04 turns on or enables interrupts, which includes the timer interrupt. Since each timer interrupt occurs every 32 milliseconds in the preferred embodiment, this will guarantee that an event occurs (and an associated read of the 8253 timer) at least once every 55 milliseconds. This is because the 8253 timer is read every time an event, including an interrupt, occurs. Now that the timer operation is understood, discussion will now turn to when the timer is read. Hooks are events that are capable of being monitored, and trigger a particular response in the data processing system. An event in OS/2 is usually described by two hooks, a pre-hook and a post-hook. For example, when an I/O request is made, the device driver generates a pre-hook signalling the system that a request is about to be made to the I/O adapter. When the adapter completes the I/O request, the device driver signals the completion of the event with a post-hook. The time between the pre- and post-hooks represents the elapse time of the event. More specifically, as events occur, such as an I/O request, the kernel servicing the events calls the SYSTRACE routine with information describing the event. This allows SYSTRACE to process the event. Each time a hook arrives at the SYSTRACE patch code, meaning that a hook was invoked and that SYSTRACE is processing it, the timer is read and the high byte incremented if necessary(i.e. if the timer rolled over, as described above). The hook is examined to see if it is one of the desired hooks. If the received hook is one that is being monitored, it is processed further. Otherwise, it is flushed, or continues on with normal processing. If the hook is an interrupt, 04/xx, the device driver measures the time spent processing interrupts. This is accomplished by matching the event called "start of an interrupt", called a pre-hook and which is generated when an interrupt handler begins to process the interrupt request, with the event "end of interrupt", called a post-hook and which is generated when an interrupt handler completes the processing of an interrupt request. As such, there is a one-to-one correspondence between pre- and post-hooks, and the timestamps of each are subtracted from one another to yield the time spent processing the interrupt. It is also possible that after a pre-hook occurs, a subsequent pre-hook occurs before a corresponding post-hook occurs for the first pre-hook. This nesting of hooks is easily handled in that any post-hook received is paired with the most recently received pre-hook. In other words, after one hook starts, another can start, but the second will end before the first will end. In this nesting scenario, the end time minus the start time, and minus all nested activities, is how long the outer event took. If the hook is a Mode Switch, 02/xx, the device driver measures the time spent in the REAL mode of the CPU by tracking the time from the first mode switch until the scheduler dispatches a different process. This time is then subtracted from the time when a mode switch to PROTECT mode occurs. If the hook is a Thread Dispatch, 12/01, the device driver first saves the process identification (PID) and thread identification (TID) from its data area (PID and TID is common terminology in OS/2 architected systems; the PID is a 16-bit number that uniquely identifies a process within the OS/2 environment. The PID value starts at 0001 and increments each time a process is created. TID's are required as several threads can exist in one process). Then, the device driver examines its data to see if it has a PID identical to the PID in the previous Thread Dispatch hook 12/01, in which case the hook is flushed. Otherwise, the time spent in Interrupts and the time spent in REAL mode is appended to the existing Thread Dispatch 12/01 data, which is the PID and TID provided by the scheduler describing the event. The entire Thread Dispatch hook is reformatted to conform to standard PERFMON/DEKOVERT format, as shown in FIG. 11a and described later, and written to one of the device driver's 32K buffers. The two registers holding the accumulated Interrupt time and the REAL mode time are then reset to zero. If the hook is a FileSystem hook, 30/xx, then the current TID 191 is inserted ahead of the Normal Data, as shown in FIG. 11b. The above listed, and other, hooks of interest are also reformatted so that they resemble the PERFMON/DEKOVERT format, and written to one of the 32K buffers. The first eight bytes of each record are the Major Code 183, the Minor Code 184, the Data Length 185, a Flag 186, and the four byte Time Tag 188, as shown in FIG. 11. The subsequent bytes shown, DD1-DDn at 189 are the hook data. When one of the buffers is full, i.e. has used 24K of its 32K space, the buffers are switched using conventional programming techniques, and the full 32K buffer is made available to the control program. Data collection continues in the other 32K buffer. The device driver also provides for swapping these buffers on a signal from the control program, in order to be able to provide the control program with data accumulated up to that point. A similar operation occurs whenever a TRACE Command is issued, 00/02, hook is received and the first data byte is 0.times.00 (meaning that TRACE has been turned off). In this case, it is mandatory that the control program receive the current buffer immediately, as there will be no further accumulation of data in either buffer. Communication between the control program and the device driver is achieved by using the communication area in the respective 32K buffer as follows. In order for the control program to reset the device driver and the device driver's buffers, the control program loads a control word in the communication area to the value `2`, as shown in Table 2. When the device driver completes a reset, it changes this a value to `1`. If the control program desires to pause the device driver and buffer filling, the control program loads a control word in the communication area to a value of `1`. When the control program desires the device driver to resume, the control program loads this control word to a value of `0`. When the control program desires to shut down, or stop, the control program unhooks the device driver as previously described. Operation is then suspended until such time that the control program sends another READ command to the device driver. DATA REDUCTION Low-level event trace performance data is transformed into high level system activities. This is accomplished by the following methodology. First, pre-hook and post-hook events are matched, as previously discussed, and then these two hooks are transformed into one event. This is because a single record can be used to replace the pre- and post-hooks since it is now known how long the event took, and this event timing is the desired granularity of information needed. Additionally, as described above, events are filtered to only use information in the event records that are of interest to the control program. APPLICATION PROGRAMMING INTERFACE (API) The following describes the application programming interface (API) to the Data Collection Facility. This API allows client applications to retrieve performance data and access the Memory Analyzer. The API is implemented through two named pipes called the System Pipe and the Trace Pipe. The System Pipe is used by a client application to send parameters to and receive responses from the Data Collection Facility. The Trace Pipe is used by a client application to receive continuous performance data. The Data Collection Facility creates both pipes; the client application issues the OS/2 function calls DosOpen and DosClose to access the pipes. Both pipes are created as message pipes in blocking mode (see the "IBM Operating System/2 Version 1.2 Programming Tools and Information" for additional information, hereby incorporated by reference as background material). System Pipe A client application controls the actions of the Data Collection Facility through the System Pipe. The client application reads from and writes to the pipe in message mode. Each message written to the pipe represents one parameter from the syntax diagram. A message must be an ASCIIZ string (that is, a null-terminated string, or one byte of binary zeros) including numbers (for example, decimal 10 must be sent as the string "10"). The Data Collection Facility sends responses back to the client application through the System Pipe. The name, used by the client application on the OS/2 function call DosOpen, of the System Pipe in a local machine is PIPE SYSTEM.SPM; on a remote server the name of the pipe is server.sub.-- namePIPE SYSTEM.SPM. Output from the Memory Analyzer (/THESEUS theseus.sub.-- command) is also sent from the Data Collection Facility to the client application through the System Pipe. First the return codes are sent. Then, output, if any, from the Memory Analyzer command is sent. Each message represents a single line from the Memory Analyzer; maximum line length is 100 characters. This output is followed by a done message represented by five pound signs (#####) followed by a null character (00). The System Pipe is disconnected by the Data Collection Facility when the client application closes the pipe with the OS/2 function call DosClose. FIG. 12 details a syntax diagram for messages that may be sent to the Data Collection Facility through the System Pipe. Syntax parameters are explained in Table 5. A parameter is represented as a contiguous set of characters. Parameters with uppercase characters are keywords. Each parameter must terminate with a null character (binary zero). For example, to send the comment "Performance data for SERVER1" to the SPM application, send the following messages:
TABLE 5
______________________________________
/COMMENT
Performance data for SERVER1
Data Collection Facility
Parameters
Parameter Action
______________________________________
/START Indicates the types of resources
about which trace pipe records are
to be sent by the Data Collection
Facility. See also Table 8-3.
*Indicates CPU, physical disk, RAM
and swap resources when used with
the /START parameter (does not
indicate logical disk). Indicates
all resources when used with the
/STOP parameter.
CPU Indicates CPU resources.
PHYSICALDISK
Indicates physical disk resources.
LOGICALDISK
Indicates logical disk resources.
RAM Indicates random access memory
resources.
SWAP Indicates swapping resources
Note: All trace pipe records without a
specific type (designated as "No
Type" in Table 8-3 are included
whenever any of the preceding
options are specified.
/STOP Indicates the types of resources about
which trace pipe records are not to be
sent by the Data Collection Facility.
See option descriptions under /START.
See also Table 8-3.
##### Done message. Indicates the end of
resource specification messages follow-
ing the /START or /STOP parameter.
/COMMENT Imbeds a comment with the collection
data.
string
Comment to be imbedded in the
current collection data.
Comments cannot be longer
than 40 characters; longer
comments are truncated to 40
characters and are accepted
without error by the Data
Collection Facility. The
string must be sent as a
separate message if it
contains embedded blanks.
/EXIT Stops capturing data and releases the
Data Collection Facility from memory.
All processes started by the Data
Collection Facility are also stopped
(IDLECPU and THESEUS).
/INITDATA Sends initialization records from the
Data Collection Facility through the
Trace Pipe. The following records are
included:
A Process Info record for the
IDLECPU process. This is the
process used by the Data Collec-
tion Facility to determine the
time the CPU was idle. This
process executes at idle priority,
level 0 (zero).
A System Info record.
A Process Info record for all
processes currently executing in
the system. These records are
only sent if the Memory Analyzer
has been started (see the /THESEUS
START parameter).
Note: The CPU resource must be started
(see the /START CPU parameter
Table 8-3) in order to receive
Process Info records.
/TOD Specifies the interval (in seconds)
between Time of Day records sent by the
Data Collection Facility through the
Trace Pipe.
interval
The number of seconds between
Time of Day records. The
range of possible values is 1
to 100 seconds. The default
is 5 seconds, but the inter-
val parameter may have been
set to another value by a
previous application.
/RAM Controls the periods used in sampling
random access memory. See the RAM
record description in Table 8-3 for
information about the samples.
Note: This parameter does not imply
/START RAM. See /START RAM at
beginning of table for more
information about enabling the
RAM resource.
working.sub.-- set.sub.-- period
The time frame, in seconds, used
in determining the amount of
physical RAM included in the
working set. Each sample repre-
sents the amount of RAM used
during the last working set
period. The range of possible
values is 5 to 3600; the default
is 60 seconds, but the work-
ing.sub.-- set.sub.-- period parameter may have
been set to another value by a
previous application.
Note: Until a full working
set period has elapsed,
the working set
represents only the
percentage of RAM in the
working set since
issuing the /RAM parame-
ter or since the working
set period was changed.
sample.sub.-- interval
The number of seconds between RAM
samples. A RAM trace pipe record
is sent each time a sample is
taken. The range of possible
values is 5 to 3600; the default
is 10 seconds, but the sam-
ple.sub.-- interval parameter may have
been set to another value by a
previous application.
Note: For performance reasons, the
SPM application requires that
the working.sub.-- set.sub.-- period parameter
value divided by the
sample.sub.-- interval parameter value
be less than or equal to 200.
/THESEUS Starts the Memory Analyzer if it has
not already been started by the Data
Collection Facility. Provides a
programming interface to the Memory
Analyzer from an application.
Note: The Memory Analyzer full-screen
interface is not available from
the copy of the Memory Analyzer
started by the Data Collection
Facility in this manner.
START Causes the Memory Analyzer to
be started if it has not
already been started by the
Data Collection Facility.
theseus-command
Any Valid Memory Analyzer
command. The theseus.sub.-- command
must be sent as a separate
message if it contains
embedded blanks.
Note: All the Memory Analyzer commands
(theseus.sub.-- command) are
interpreted directly by the
Memory Analyzer, including the
THESEUS LOG command. All
actions will occur from the
reference point of the Memory
Analyzer started by the Data
Collection Facility as though
they were typed at the Memory
Analyzer full-screen interface.
/NOTHESEUS
Terminates the Memory Analyzer if it
has been started by the Data Collection
Facility. This saves the RAM overhead
associated with the Memory Analyzer on
the collection machine. However,
Process Info records for processes
currently executing in the system
(excluding the IDLECPU process) are not
sent through the Trace Pipe. This
includes processes executing when the
/INITINFO parameter is sent.
/DEBUG Indicates that the Data Collection
Facility is to log parameters it
receives from client applications to
the log file SPMLOG.LOG in the working
directory.
______________________________________
One status message is sent to the client application by the Data Collection Facility for every parameter that has a slash (/) as its first character. This status message provides an indication of the success of the request from the parameter. The format of a status message is described in the following table.
______________________________________
SPM Return Code 2 Bytes
(Word)
Service Return Code 2 Bytes
(Word)
Reserved 2 Bytes
(Word)
______________________________________
Next, the output from any Memory Analyzer commands specified with the /THESEUS parameter (theseus.sub.-- command) is sent to the client application. Each message represent a single line from the Memory Analyzer. A done message (#####) follows this output. Values that may be returned in the SPM return code field are contained in Table 6. All values are given in hexadecimal.
TABLE 6
______________________________________
SPM Return Codes
Code Description
______________________________________
X'0000'
No error, the parameters were accepted.
X'0007'
Invalid parameter. The service return code
contains the sequence number of the parame-
ter that failed. Each parameter beginning
with a slash (/) will reset the sequence
number to 1.
X'0010'
The working.sub.-- set.sub.-- period value is out of range
(/RAM parameter).
X'0011'
The sample.sub.-- interval value is out of range
(/RAM parameter).
X'0012'
The sample.sub.-- interval value is not a multiple
working.sub.-- set.sub.-- period value (/RAM parameter).
X'0013'
The working set.sub.-- period value divided by the
sample.sub.-- interval value is greater than 200
(/RAM parameter).
X'0014'
The /TOD interval value is out of range.
X'0108'
Unable to issue the TRACE.EXE ON command to
the OS/2 system through the OS/2 function
call DosExecPgm.
X'0208'
Unable to issue the TRACE.EXE OFF command to
the OS/2 system through DosExecPgm.
X'0408'
Unable to start the IDLESPU.EXE program
through the OS/2 function call
DosKillProcess.
X'0409'
Unable to stop the IDLESPU.EXE program
through the OS/2 function call
DosKillProcess.
X'0806'
The Memory Analyzer does not recognize this
OS/2 version.
X'0807'
Unable to communicate with the Memory
Analyzer.
X'0808'
Unable to start the THESEUS.EXE program
through the OS/2 function call DosExecPgm.
X'0809'
Unable to stop the THESEUS.EXE program
through the OS/2 function call
DosKillProcess.
X'1003'
The device drive THESEUS.SYS was not loaded
from the CONFIG.SYS file.
X'1005'
An invalid version of the device driver
THESEUS.SYS was not loaded from the
CONFIG.SYS file.
X'2003'
The device driver SPMDCF.SYS is missing in
the CONFIG.SYS file.
X'2004'
Errors occurred while initializing the
SPMDCF.SYS device driver through DosOpen or
DosRead.
______________________________________
Note:
The service return code is the return code from the requested OS/2 servic
unless otherwise mentioned in this table.
TRACE PIPE The Trace Pipe is used by a client application to retrieve performance data from the Data Collection Facility. The Trace Pipe is a one-way named pipe: Data Collection Facility to client application. On a stand-alone machine, the name of the pipe, as used by the client application on the DosOpen function call, is PIPE TRACE.SPM; on a remote server, the pipe name is server.sub.-- namePIPE TRACE.SPM. The Trace Pipe is a message stream named pipe (as opposed to a byte stream named pipe) with a maximum message length of 8 kilobytes. The client application should send a /STOP or /EXIT message on the System Pipe to stop the collection and transmission of performance data through the Trace Pipe. Data is queued in a buffer by the Data Collection Facility before transmission through the Trace Pipe. Messages on the Trace Pipe contain one or more complete trace pipe records. A message is transmitted through the pipe at least every 4 seconds, provided data is available. The sequence of actions a client application would take to collect performance data from the Data Collection Facility is as follows: 1. Open the System Pipe. 2. Send appropriate messages to the Data Collection Facility (SPMDCF) through the System Pipe (including the /START message), obtaining return codes as applicable. 3. Open the Trace Pipe. Read data from the Trace Pipe until ready to stop collecting. 5. Send a /STOP or /EXIT message to Data Collection Facility through the System Pipe, obtaining return codes as applicable. 6. Close the System and Trace Pipes. TRACE PIPE RECORD FORMAT The general format of records sent through the SPM Trace Pipe is:
______________________________________
Variable Length
Length of Record
Trace Pipe Code
Data
______________________________________
(1 byte) (1 byte) (max. 250 bytes)
______________________________________
TRACE PIPE RECORDS The records listed in FIGS. 13A-C may be sent from the SPM application to a client application through the Trace Pipe. TABLE DEFINITIONS ASCIIZ string A string of characters followed by a nullcharacter (ASCII 00). Maximum number of characters is 250. data overflow Indicates that data has been discarded by the Data Collection facility. Usually this occurs if the client application is not reading data from the Trace Pipe quickly enough. doubleword 4 bytes in Intel format (that is, byte/word-reversed). In IBM C/2, this is an unsigned long integer (ULONG). elapsed time Total timertics encountered during the operation. This is not to be interpreted as time the operation was busy using the CPU, but rather, the time between when a request was submitted and when the operation completed. For example, a swap request is made by the swapper; then the swapper may give up the CPU to another process until disk I/O can complete; then the swapper completes the operation. The elapsed time includes the entire time, including the time the swapper was blocked waiting for the disk. ID of the first physical disk The ID assigned to the first physical disk by the system. Each physical disk is assigned a sequential number, beginning with the ID assigned to the first physical disk. number of physical disks The total number of physical disks installed in the system. number of sectors Number of 512-byte sectors. physical disk ID The ID assigned to the physical disk. process name This is the name of the process defined in the .EXE header or the file name of the .EXE file (does not include a period or the file extension). time executing previous process Total timertics encountered while executing the previous process (includes time spent at interrupt level [time in interrupts previous process]). time in interrupts previous process Total timertics encountered while at interrupt level while executing the previous process. time since last Time of Day record The elapsed timertics since the last record was sent. This value is provided for accurate calculations. timertic A value derived from the 8253/8254 chip. This value can be converted to microseconds by multiplying the value by 0.8380953445; that is: microseconds=timertics.times.0.8380953445. TRACECMD Indicates that the user issued a trace command. word 2 byes in Intel format (that is, byte-reversed). In IBM C/2, this is an unsigned short integer (USHORT). GRAPHICAL PRESENTATION In order to graphically depict the resource utilizations or performance monitors described above, the preferred embodiment of this invention uses OS/2 Presentation Manager window and graphics functions. This method allows a user to view multiple groups of related information in multiple windows (or viewports) simultaneously. One main window, called the parent window, contains all the other windows, called child windows, that display resource utilization information. As shown in FIG. 6, the resource information is presented in the form of graphs which display percentage utilization of a certain data processing system resource. The resource utilization data is displayed to represent a user-configurable period of time (e.g. the last 600 seconds), or the viewing period 122 of FIG. 7b. Thus, it provides both instantaneous and recent/past records of resource utilization. A user can choose to view some or all of the resource monitors, as well as modify the display characteristics of the windows. Other information, or the same information in other forms, could be presented in the child windows. Presentation parameters, which control how, and when, the data is displayed in the child windows are changeable by the user from the main window's menu (action) bar. As will be appreciated to those of ordinary skill in the art, standard windows programming techniques are used to present the desired graphical representation to the OS/2 Presentation Manager interface. The Presentation Manager is the entity that actually presents the data in a display window or viewport. Other operating systems, such as DOS in combination with Microsoft's Windows .sup.2 HP's New Wave.sup.3, XWindows.sup.4 or AIXWindows.sup.5 provide similar programming interfaces to a window-like presentations and could similarly be used in the presentation of resource monitors in their respective systems, without departing from the spirit and scope of the present invention. .sup.2 Trademark of Microsoft Corp. .sup.3 Trademark of Hewlett-Packard Corp. .sup.4 Trademark of M.I.T. .sup.5 Trademark of IBM Corp. Finally, FIG. 14 depicts are generalized data processing system which is the preferred embodiment of this invention. A CPU 190, RAM 194, and peripheral device 196 (shown as a direct access storage device, or DASD), and interconnected via a bus structure. Similarly, ROS 192 and a keyboard 198 having an pointer/input device 200 are attached to this bus 204. These are the resources capable of being monitored in the preferred embodiment. Also attached to this bus is a display means 202, capable of rendering the resource monitor's results to a user. This display means is similarly attached to the common bus 204. Other variations having high speed paths between specific devices, and not a general bus as shown, would similarly fall within the realm of this invention, and would not be a departure from the scope of spirit of the herein claimed invention. As has been shown in the above description, this data processing system utilization monitor with tracing provides for real-time performance monitoring without specialized hardware and without significant impact to the system performance being monitored. While we have illustrated and described the preferred embodiments of our invention, it is to be understood that we do not limit ourselves to the precise construction herein disclosed and the right is reserved to all changes and modifications coming within the scope of the invention as defined in the appended claims. ##SPC1##
|
Same subclass Same class Consider this |
||||||||||