 |
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.
CROSS REFERENCE TO RELATED PATENT APPLICATIONS
Ser. No. 07/713,484, filed Jun. 10, 1991 for REAL TIME SYSTEM RESOURCE MONITOR FOR DATA PROCESSING SYSTEM, now abandoned, and assigned to the same assignee as the present invention and hereby incorporated by reference.
Ser. No. 07/713,471, filed Jun. 10, 1991 for REAL TIME SYSTEM RESOURCE MONITOR FOR DATA PROCESSING SYSTEM WITH SUPPORT FOR DYNAMIC VARIABLE UPDATE AND AUTOMATIC BOUNDING, now abandoned, and assigned to the same assignee as the present invention
and hereby incorporated by reference.
Ser. No. 07/713,486, filed Jun. 10, 1991 for REAL TIME INTERNAL RESOURCE MONITOR FOR DATA PROCESSING SYSTEM, now abandoned, and assigned to the same assignee as the present invention and hereby incorporated by reference.
Ser. No. 07/965,982, filed Oct. 23, 1992 for SYSTEM AND METHOD MAINTAINING PERFORMANCE DATA IN A DATA PROCESSING SYSTEM, currently co-pending, and assigned to the same assignee as the present invention, which is hereby incorporated by
reference.
Ser. No. 07/965,956, filed Oct. 23, 1992 for SYSTEM AND METHOD FOR CONCURRENT RECORDING AND DISPLAYING OF SYSTEM PERFORMANCE DATA, currently co-pending, and assigned to the same assignee as the present invention, which is hereby incorporated by
reference.
Ser. No. 07/965,959, filed Oct. 23, 1992 for SYSTEM AND METHOD FOR DISPLAYING SYSTEM PERFORMANCE DATA, currently co-pending, and assigned to the same assignee as the present invention, which is hereby incorporated by reference.
Ser. No. 07/965,960, filed Oct. 23, 1992 for SYSTEM AND METHOD FOR REAL TIME VARIABLE GRANULARITY RECORDING OF SYSTEM PERFORMANCE DATA, currently co-pending, and assigned to the same assignee as the present invention, which is hereby
incorporated by reference.
Ser. No. 07/965,981, filed Oct. 23, 1992 for SYSTEM AND METHOD FOR MONITORING AND OPTIMIZING PERFORMANCE IN A DATA PROCESSING SYSTEM, currently co-pending, and assigned to the same assignee as the present invention, which is hereby incorporated
by reference.
Ser. No. 07/965,953, filed Oct. 23, 1992 for SYSTEM AND METHOD FOR ANNOTATION OF REAL TIME DATA IN A DATA PROCESSING SYSTEM, currently co-pending, and assigned to the same assignee as the present invention, which is hereby incorporated by
reference.
TECHNICAL FIELD
This invention relates to the area of data processing systems, and more particularly to the field of performance tools used to analyze the operations of data processing systems.
BACKGROUND ART
As data processing systems continue to grow in complexity, traditional tools used in the development, design and debug of such systems become increasingly impractical to use. For example, in the development and design of personal computers, an
engineer could use a logic analyzer and oscilloscope to assist in locating errors in hardware and software. As the software running on these data processing systems became more complex, tools such as in-circuit emulators were developed, whereby the
instruction flow of a central processing unit (CPU) could be captured and analyzed. These types of tools still require a large amount of human intervention and human analysis to assist in problem determination.
Various types of software tools have been introduced in the marketplace to assist in monitoring a data processing system, such as the System Performance Monitor/2 from IBM. This tool provides a graphical interface to visual depict various
aspects of a data processing system, and greatly reduces the amount of time required to analyze the operation of a data processing system. Although these systems provide a substantial improvement over previous methods for monitoring and analyzing a data
processing system, there are still certain deficiencies. First, they are geared towards hardware resources in a data processing system, and do not fully address the ability to monitor software processes or applications. Secondly, the flexibility and
granularity provided are limited. Further, performance data is merely output to a user display device, and thus does not provide full flexibility in analyzing the data being captured.
Network monitoring tools such as IBM NetView/6000 (TM) programs are concerned primarily with supervision and corrective action aiming at keeping the network resources available and accessible. Resource availability is the concern of such tools,
rather than resource utilization. For example, IBM NetView/6000 tracks the amount of free space of a disk.
There is a need to provide a data processing system performance tool that is flexible and easy to use, that can monitor hardware as well as software events and process activities, that can capture data (e.g. read sampled data) for subsequent
retrieval and analysis, and that provides other facilities to further analyze and categorize such captured data.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a highly flexible analysis tool for a data processing system.
It is a further object of the present invention to provide a performance tool for a data processing system.
It is yet a further object of the present invention to provide a tool for monitoring, capturing, saving, retrieval and analysis of data processing system operations.
These objects and others are accomplished by a performance tool, its related application programming interfaces and the performance daemon are designed for interactive selection of performance statistics across a network of computer systems, the
control of the flow of performance data, and the monitoring of the remote host(s) performance in live graphs.
Some of the key aspects of the design are in the combination of (1) graphical monitoring of remote data in highly customizable graphs capable of combining plotting styles; (2) the monitoring program is not required to know which hosts in the
network can supply statistics and which statistics are available from each host; (3) interactive exploration of the sources of statistics on the network and the collection of statistics available from each source; and (4) the negotiation of what data
systems processes to monitor across the network.
A computer system is made up of a variety of different types of hardware and software components, such as network nodes, CPUs, memory, processes, etc. In the field of performance analysis, these objects represent different contexts for the
collection of performance data, and the computation of performance statistics.
Since the computing environment can be decomposed into successively smaller and smaller components, it defines a hierarchy of these performance analysis contexts. In the xmperf performance tool disclosed herein, all statistics are associated
with particular contexts, and these contexts are identified by listing all the contexts which are traversed in going from the top-level context to that context. For example, in the case of a network-based computing environment, the disk called "hdisk0"
on the host called "ultra", would be referenced by using the following path:
The statistic for the number of read operations on this disk can then be referenced by adding the statistic name to the above path:
The set of hosts on a particular network, and the configuration of any one system, may vary greatly from environment to environment and from time to time. Furthermore, the resource monitoring tool is faced with the problem of monitoring
entities, such as processes, that are created dynamically and disappear without warning. Thus, obviously, a statically defined context hierarchy would not be adequate, and instead, the context hierarchy must be dynamically created and modifiable at
execution time.
In the performance tool (xmperf), this problem is handled by using an object oriented model. In this model, a generic hierarchy of performance statistics contexts is defined using a hierarchy of context classes. Statistics are attributes of
these classes, and generally all instances of a particular context class will have the same set of statistics. For example, the statistics relevant to the class of "disks" might include: "busy time", "average transfer rate", "number of reads", "number
of writes", etc. Each class also has a "get.sub.-- data()" method (i.e. function) for each statistic, which can be called whenever that statistic needs to be computed.
In xmperf, context classes also contain an "instantiate()" method, which is called to create object instances of that class. For example, this method could be used for the class of "disks" to generate performance analysis contexts for collecting
data on each disk in a particular system, (e.g. "hdisk0", "hdisk1", etc.). These disk contexts would all have the same set of statistics and "get.sub.-- data()" methods, which they inherit from the "disks" class.
A client/server model was implemented to allow performance monitoring over a network, typically (but not necessarily) a Local Area Network (LAN). The model is implemented with a server program, known as a "Data Supplier", that runs as a daemon
on the server system and one or more client programs, called "Data Consumers", which are providing the monitoring facilities.
The Data Supplier daemon:
.smallcircle. Has its statistical data organized in a hierarchy to provide a logical grouping of the data.
.smallcircle. Upon request over the network, and on a selective basis, presents what statistics it has available.
.smallcircle. Accepts subscriptions for a continuous flow of one or more sets of performance data at negotiable frequency.
.smallcircle. Provides for dynamic extension of its inventory of statistics through a simple application programming interface.
The Data Consumer Programs:
.smallcircle. May be the developed graphical monitoring program as is described in more detail below.
.smallcircle. May be a user-developed (application) program using the developed application programming interface to negotiate the set(s) of statistics in which it is interested with one or more Data Supplier daemons and to receive, process,
display, and take corrective action based on the statistics as they are received from the Data Supplier(s) over the network.
An important design objective was to make sure that a Data Consumer program does not need any prior knowledge of the statistics available from Data Suppliers. This was further emphasized by the fact that not all hosts in a network have identical
configurations and abilities and thus can not supply identical collections of statistics. The solution was to allow Data Consumers to negotiate with potential Data Suppliers. The implementation is a low cost, Transmission Control Protocol (TCP)/User
Datagram Protocol (UDP) based protocol with the following message types:
.smallcircle. Control messages to identify potential Data Suppliers on the network and to check whether partners are still alive
.smallcircle. Configuration messages to learn about the statistics available from identified suppliers and to define subscriptions for data
.smallcircle. Data Feed and Feed Control messages to control the continuous flow of data over the network
.smallcircle. Status messages to query a Data Supplier's status
.smallcircle. Messages to register additional statistics with the Data Supplier daemon.
The protocol allows for up to 124 individual values being grouped into a set and sent across the network in a single packet. A value is the finest granularity of statistic being monitored and has attributes associated with it. The simple
application program interface hides the protocol from the application programmer and isolates it from application programs. This isolation largely makes application programs unaware of future protocol extensions and support for other base protocols.
The performance monitor tool is the most visible part of the project. It is an OSF/Motif based program (OSF/Motif is a trademark of the. Open Software Foundation) that allows a user to interactively select the relevant data to monitor while
also permitting a predetermined set of monitoring "devices" to be maintained. It also provides the interface for interaction with a user to control processes within a data processing system.
The basic monitoring device is called a monitor. It shows as a window on the display and can be activated or deactivated from popup or pulldown menus.
Multiple monitors can be active at a time. Within a monitor, one or more sets of data processing system statistics may be observed in subwindows called instruments. An instrument can monitor a set of statistics supplied from any host on the
network that runs the Data Supplier daemon. A set of statistics can be selected from among the complete collection of statistics available from the Data Supplier. Instruments can graphically display their sets of statistics in many different graph
formats.
The most versatile of the graph formats shows the statistics on a time scale with each statistics value being plotted in one of four plotting styles:
.smallcircle. Line graph
.smallcircle. Skyline graph (squared-off line graph)
.smallcircle. Area graph (filled line graph)
.smallcircle. Bar graph
Proper selection of plotting style allows the superimposing of data values upon others permitting easy correlation of performance data. Another facility allows cumulative plotting of a subset of the values in a set.
The foregoing and
other objects, features, and advantages of the invention will become more apparent from the followed detailed description of the preferred embodiment which proceeds with reference to the accompanying drawing.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 depicts the subsystem components comprising the performance tool.
FIG. 2 depicts the playback and recording system interface to a recording file.
FIG. 3 depicts system interactions with the configuration subsystem.
FIG. 4 depicts system interactions with the data display subsystem.
FIG. 5 depicts system interactions with the recording subsystem.
FIG. 6 depicts system interactions with the playback subsystem.
FIG. 7 depicts system interactions with the data value receiver subsystem.
FIG. 8 depicts system interactions with the network send/receive subsystem.
FIG. 9 is a flow diagram of the operations of the recording subsystem.
FIG. 10 depicts the recording subsystem interfaces to the overall performance tool system.
FIG. 11 is a table showing allowable actions from various menu selections.
FIGS. 12a-12e depict various displays generated by the performance tool.
FIG. 13 depicts the playback subsystem interfaces to the overall performance tool system.
FIG. 14 depicts concurrent operations between multiple data processing systems.
FIG. 15 is a flow diagram of the internal operations of the playback subsystem.
FIG. 16 is a flow diagram of the internal operations of the data display subsystem.
FIG. 17 is a flow diagram of the internal operations of the configuration subsystem.
FIG. 18 is a flow diagram of the internal operations of the data value receiver subsystem.
FIG. 19 is a flow diagram of the internal operations of the network send/receive interface.
FIG. 20 is a flow diagram of the internal operations of the graphical user interface.
FIG. 21 depicts the graphical user interface subsystem interfaces to the overall performance tool system.
FIG. 22 depicts the interface between a data supplier daemon and a dynamic data supplier.
FIG. 23 is a flow diagram of the internal operations of the data supplier daemon.
FIG. 24 is a flow diagram of the internal operations of the xmpeek utility.
FIG. 25 depicts the data supplier daemon interfaces to the overall performance tool system.
FIG. 26 shows an example of output generated from the sample program listed in Appendix A.
FIGS. 27A-27B are a C language program of a dynamic data supplier program using the daemon application programming interface to provide extensions for supplying additional types of data.
FIGS. 28a-28b are flow diagrams of the internal operation for annotation and marking of data.
FIG. 29 is a flow diagram of the internal operation for a pathology library system.
FIG. 30 is a block diagram of the filtering and alarm capabilities of the performance tool.
FIG. 31 is a flow diagram of the internal operations of the filtering and alarm utility filtd.
FIG. 32 depicts a data recording file having marker token for supporting annotations.
FIG. 33 depicts the preferred embodiment data processing system.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
As shown in FIG. 1, the performance tool 90 can be perceived as consisting of five subsystems and two interfaces. The following sections describe each of these components.
GRAPHICAL USER INTERFACE
The performance tool's graphical user interface (GUI) 80 allows the user to control the monitoring process almost entirely with the use of a pointing device (e.g. a mouse or trackball). The GUI 80 uses menus extensively and communicates directly
to the following four subsystems:
GUI TO RECORDING SUBSYSTEM
The GUI 80 allows the user to start and stop recording from any active monitoring console and any active monitoring instrument. When recording begins in the recording subsystem 20, the configuration of the entire monitoring console is written to
a recording file (100 of FIG. 2). The recording file 100 itself is named from the name of the monitoring console from which it is being recorded.
As all information about the monitoring console's configuration is stored in the recording file 100, playback can be initiated without a lengthy interaction between user and playback subsystem 50. Through the GUI 80, the user can start and stop
recording as required and if a recording file already exists when recording is requested for a monitoring console, the user is given the choice of appending to the existing file or replacing it.
GUI TO CONFIGURATION SUBSYSTEM
The configuration subsystem 30 has two means of acquiring information about the monitoring of consoles and instruments. First, a configuration file (110 of FIG. 3) can contain configuration information for many monitoring devices. These may be
skeleton consoles or may be fixed consoles. Second, the user can add, change, and delete configuration about fixed consoles directly through the GUI 80. Whether configuration information is read from the configuration file or established in interaction
with the user, it causes configuration messages to be exchanged between the configuration subsystem 30 and the network send/receive interface 70 and the remote data supplier daemon(s) (210 of FIG. 8).
The skeleton consoles are monitoring devices where the exact choice of the performance data to display is left open. To activate a skeleton console, | | |
