System and Application Data That You Can Monitor


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Administering a BEA Tuxedo Application at Run Time \| Local Topics \| Previous Topic \| Next Topic \| Contents

The BEA Tuxedo system enables you to monitor system and application data.

Monitoring System Data

To help you monitor a running system, your BEA Tuxedo system maintains parameter settings and generates statistics for the following system components:

Clients
Conversations
Groups
Message queues
Networks
Servers
Services
CORBA Interfaces
Transactions

You can access these components using the MIB or tmadmin. You can set up your system so that it can use the statistics in the bulletin board to make decisions and to modify system components dynamically, without your intervention. With proper configuration, your system can perform the following tasks (when bulletin board statistics indicate that they are required):

Turn on load balancing
Start a new copy of a server
Shut down servers that are not being used

By monitoring the administrative data for your system, you can prevent and resolve problems that threaten the performance, availability, and security of your application.

Where the System Data Resides

To ensure that you have the information necessary to monitor your system, the BEA Tuxedo system provides the following three data repositories:

Bulletin board—a segment of shared memory (on each machine in your network) to which your system writes statistics about the components and activities of your configuration
Log files—files to which your system writes messages
UBBCONFIG—a text file in which you define the parameters of your system and application

Monitoring Dynamic and Static Administrative Data

You can monitor two types of administrative data that are available on every running BEA Tuxedo system: static and dynamic.

What Is Static Data?

Static data about your configuration consists of configuration settings that you assign when you first configure your system and application. These settings are never changed without intervention (either in realtime or through a program you have provided). Examples include system-wide parameters (such as the number of machines used) and the amount of interprocess communication (IPC) resources (such as shared memory) allocated to your system on your local machine. Static data is kept in the UBBCONFIG file and in the bulletin board.

Checking Static Data

At times you may need to check static data about your configuration. For example, you may want to add a large number of machines without exceeding the maximum number of machines allowed in your configuration (or allowed in the machine tables of the bulletin board). You can look up the maximum number of machines allowed by checking the current values of the system-wide parameters for your configuration (one of which is MAXMACHINES).

You may be able to improve the performance of your application by tuning your system. To determine whether tuning is required, you need to check the amount of local IPC resources currently available.

What Is Dynamic Data?

Dynamic data about your configuration consists of information that changes in realtime, that is, while an application is running. For example, the load (the number of requests sent to a server) and the state of various configuration components (such as servers) change frequently. Dynamic data is kept in the bulletin board.

Checking Dynamic Data

Dynamic configuration data is useful in resolving many administrative problems, as demonstrated by two examples.

In the first example, suppose your throughput is suffering and you want to know whether you have enough servers running to accommodate the number of clients currently connected. Check the number of running servers and connected clients, and the load on one or more servers. These numbers help you determine whether adding more servers will improve performance.

In the second example, suppose you receive multiple complaints about slow response from users when making particular requests of your application. By checking load statistics, you can determine whether increasing the value of the BLOCKTIME parameter would improve response time.