HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX |
||
As an administrator, you must ensure that once your application is up and running, it meets (and continues to meet) the performance, availability, and security requirements your company has set for it. To perform this task, you need to monitor the resources (such as shared memory), activities (such as transactions), and potential problems (such as security breaches) in your configuration, and take any corrective actions that are necessary.
To help you meet this responsibility, the WLE and BEA TUXEDO systems provides tools that enable you to oversee both system events and application events. This chapter explains how to use these tools to keep your application performing fast, well, and securely.
Specifically, this chapter discusses the following topics:
This section describes the types of data available for monitoring a running system and explains how to use that data.
Your WLE or BEA TUXEDO system maintains parameter settings and generates statistics for the following system components:
Overview of System and Application Data
Components and Activities for Which Data Is Available
To ensure that you have the information necessary for monitoring your system, the WLE or BEA TUXEDO system provides the following three data repositories:
Where the Data Resides
UBBCONFIG-an ASCII file in which you define the parameters of your system and application
This chapter describes the data stored in the The administrative data provided by your WLE or BEA TUXEDO system allows you to monitor a multitude of potential trouble areas on your system. For example, this data allows you to:
UBBCONFIG file and in the Bulletin Board, and provides instructions for monitoring that data. For a description of the log files, see Chapter 13, "Monitoring Log Files." How You Can Use the Data
Thus, by monitoring the administrative data for your system, you can prevent and resolve problems that threaten the performance, availability, and security of your application.
Two types of administrative data are available on every running WLE and BEA TUXEDO system: static and dynamic.
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 real-time or through a program you have provided). Examples include system-wide parameters (such as the number of machines being used) and the amount of IPC resources (such as shared memory) allocated to your system on your local machine. Static data is kept in the At times you will need to check the static data about your configuration. For example:
Types of Data
Static Data
UBBCONFIG file and in the Bulletin Board.
MAXMACHINES).
Dynamic data about your configuration consists of information that changes in real time, 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.
You will need to check the dynamic data about your configuration frequently. For example:
Dynamic Data
These numbers will help you determine whether adding more servers is likely to improve performance.
BLOCKTIME.
To monitor a running application, you need to keep track of the dynamic aspects of your configuration and sometimes check the static data. Thus, you need to be able to watch the Bulletin Board on an ongoing basis and consult the
Which method is best for you? The answer depends on your answers to several questions.
Monitoring Methods
UBBCONFIG file when necessary. The WLE and BEA TUXEDO system provides the following methods of doing both tasks, as shown in this table.
If you have a lot of experience as an administrator (and shell programming expertise), you may prefer to write programs that automate your most frequently run commands.
If not, you may be most comfortable using the Web-based GUI.
If you decide to monitor your system at run time through the This section provides the following information:
tmadmin command interpreter, continue reading; this chapter describes tmadmin and explains how to use it.
Using the tmadmin Command Interpreter
tmadmin session, including:
tmadmin sessions and instructions for invoking them
tmadmin commands
tmadmin for most tasks
Instructions for individual tasks are provided in later sections of this chapter.
The
Note:
How might you want to use What is tmadmin?
tmadmin command is an interpreter for 50 commands that let you view and modify a Bulletin Board and its associated entities.
tmadmin is supported on UNIX and Windows NT platforms.
tmadmin to modify your system while it is running? Consider the following sample scenario. Suppose you want to check the current values for all the parameters listed in the Bulletin Board, such as maximum number of servers and services. You can do this by running the tmadmin command, bbparms.
How a tmadmin Session Works
tmadmin session starts when you (the administrator) enter the tmadmin
command at a shell prompt. The shell prompt($) is replaced by the tmadmin
prompt (>) which is used until you quit tmadmin.
You can request one of three operating modes on the command line: the default mode (which allows you to view and change the Bulletin Board and associated entities), read-only mode ($ tmadmin [
operating_mode_option]
>-r), or configuration mode (-c).
tmadmin verifies that the configuration is running. If the configuration is not
running the following message is displayed:
No bulletin board exists. Entering boot mode
>tmadmin checks the TUXCONFIG and TUXOFFSET environment variables to get the
location and offset at which the configuration file has been loaded. (Be sure you
have defined these variables before beginning a tmadmin session.)
tmadmin with no options), tmadmin enters the Bulletin Board as an administrative process, allowing you to view and make changes to configuration components and/or activities listed in the Bulletin Board.
> prompt is displayed on your screen and you enter a tmadmin command.
tmadmin session
For details, see the tmadmin(1) reference page in the BEA TUXEDO Reference Manual.
Whenever you start a tmadmin session, you have a choice of operating modes for that session: read-only mode, configuration mode, or the default operating mode. In addition, you can generate a report of the WLE or BEA TUXEDO version and license numbers.
In this mode, you can view the data in the Bulletin Board, but you cannot make any changes. The advantage of working in read-only mode is that your administrator process is not tied up by tmadmin; the tmadmin process attaches to the Bulletin Board as a client, leaving your administrator slot available for other work.
To start a tmadmin session in read-only mode, specify the -r option on the command line:
$ tmadmin -r
In this mode, you can view the data in the Bulletin Board and, if you are the BEA TUXEDO application administrator, you can make changes. You can start a tmadmin session in configuration mode on any machine, including an inactive machine. On most inactive machines, configuration mode is required. (The only inactive machine on which you can start a tmadmin session without requesting configuration mode is the MASTER machine.)
To start a tmadmin session in configuration mode, specify the -c option on the command line:
$ tmadmin -c
If you want to view and change Bulletin Board data during a tmadmin session, you must:
UID and GID must be those of
the administrator).
To find out which version of the WLE or BEA TUXEDO system you are running and to get the license number for it, specify the -v option on the command line:
$ tmadmin -v
After displaying the version and license numbers, tmadmin exits, even if you have specified -c or -r in addition to -v. When -v is requested, all other options are ignored.
The tmadmin command interpreter is equipped with a set of meta-commands, commands that help you use tmadmin. Table 15-1 lists the tmadmin meta-commands.
Note:
The tables and examples in this chapter include the abbreviated forms of the tmadmin command names.
The default meta-command (d) lets you set and unset defaults for the following frequently used parameters for most tmadmin commands: group name, server ID, machine, user name, client name, queue address, service name, device blocks, device offset, and UDL configuration device path. (For details, see the tmadmin(1) reference page in the BEA TUXEDO Reference Manual.)
Note:
You cannot assign defaults to any parameters for the boot and shutdown commands.
Once defaults are set, they remain in effect until the session ends or until the parameters are reset to different values. The remainder of this section provides a list of instructions for checking, setting, and unsetting defaults:
default meta-command without any options. Listing 15-1 shows an example of the report that is displayed when no parameters are set.
Listing 15-1
Default Output
> d
Default Settings:
Group Name: (not set)
Server ID: (not set)
Machine ID: (not set)
Queue Name: (not set)
client Name: (not set)
Service Name: (not set)
User Name: (not set)
Blocks: 1000
Offset: 0
Path: /home/apps/bank/bankdll # Path defaults to value of FSCONFIG
>
default command, specifying the parameter, as follows:
For example, to change the default of the service name to "teller," enter the following command:
default -
parameter new_valuedefault -s teller
default command with the appropriate option for the parameter in question, followed by the * wildcard argument.
For example, to unset the default for the service name (specified with the - For most parameters, when you unset the default setting without specifying a new one, the result is that you have no default for that parameter. This generalization does not apply to the machine ID parameter, however.
In a multiprocessor environment, the value of the machine ID can be a specific processor, the DBBL, or default -parameter *s argument), enter the following command:
default -s *
all. If the value of the machine ID is a specific processor, information is retrieved only from that processor. To remind you of this fact, the logical machine ID is added to the tmadmin session prompt (LMID >), as shown in Listing 15-2.
Listing 15-2
Prompt When Machine ID Is Set to a Specific Processor
# 1. default mid not previously set
> d -m SITE1 # 2. set SITE1 as default mid
SITE1 > # 3. prompt now shows default mid
If you unset the current default of the machine ID without specifying a new default, the DBBL is used, automatically, as the new default. In other words, if you enter
default -m *
DBBL becomes the machine ID. You can also simply specify DBBL as the new machine by entering the following:
default -m DBBL
Most tmadmin commands require explicit information about the resource on which the command is to act. Required arguments can always be specified on the command line, and can often be set via the default command, as well. tmadmin reports an error if the required information is not available from either source.
Some tmadmin statistical commands interpret unspecified default parameters as all.
This section provides the basic procedure for running tmadmin commands. Commands for doing specific monitoring tasks through tmadmin are provided in the section "Monitoring a Running System with tmadmin" in this chapter.
Note:
For complete details about tmadmin, see the tmadmin(1) reference page in the BEA TUXEDO Reference Manual.
Perform the following steps to run the tmadmin commands.
TUXCONFIG and TUXOFFSET environment variables have been set.
tmadmin in the appropriate operating mode.
-c option on the tmadmin command line.
-r option on the tmadmin command line.
tmadmin session prompt (>) is displayed, enter your first tmadmin
command. Specify, on the command line, how much information from the
Bulletin Board you want to have displayed.
For example: bbparms -v
For example: bbparms -t
tmadmin command, continue entering
tmadmin commands until you are ready to end the session.
Table 15-2 provides a list of potential problems that you might want to check while monitoring your run-time system, along with a list of the tmadmin commands that enable you to perform such a check. The table also suggests follow-up actions you might take if the tmadmin command you run generates a particular type of output.
Note:
For a comprehensive list of the tmadmin commands, see the tmadmin(1) reference page in the BEA TUXEDO Reference Manual.
This section provides examples of output from the following tmadmin monitoring commands:
printqueue
The following output from the
Note:
By default, information is supplied for all queues. If you want your output to be limited to information about only one queue, specify the address for the desired queue.
The output of this command includes the following information:
The following (verbose) output from the printqueue Output
printqueue command lets you check the distribution of work in the bankapp application.
printqueue [qaddress]
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
>pq printconn Data
printconn command shows that the client process has:
This section shows the output from the following procedure.
printnet Command Output
printnet command was run. (The output shows the number of messages sent
and received by both sites.)
The printtrans command reports statistics only for transactions that are currently in progress, specifically, statistics on the number of rollbacks, commits, and aborts that have been executed on your machine, group, or server.
This section shows the output produced by running the printtrans command in terse and verbose modes:
GTRID (a unique string that identifies a transaction across an application) and the transaction state are shown.
Note:
The index shown in the example is used by the administrator to commit or abort the transaction.
printtrans [-m machine] [-g groupname]
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> pt
>> index=0>gtrid=x0 x2bb8f464 x1
: Machine id: SITE1, Transaction status: TMGACTIVE
Group count: 1
> v
Verbose now on.
> pt
>> index=0>gtrid=x0 x2bb8d464 x1
: Machine id: SITE1, Transaction status: TMGACTIVE
Group count: 1, timeout: 300, time left: 299
Known participants:
group: GROUP1, status: TMGACTIVE, local, coord
>
This section presents a sample configuration for a multiprocessor (MP) version of the For this case study, we will use the configuration defined in the Case Study: Monitoring Run-time bankapp
bankapp application. This section also shows the output that was returned when the local IPC resources and system-wide parameters were checked by running the appropriate tmadmin commands.
Configuration File for bankapp
UBBCONFIG file shown in Listing 15-3.
Listing 15-3
UBBCONFIG File for bankapp (MP Version)
#Copyright (c) 1997, 1998 BEA Systems, Inc.
#All rights reserved*RESOURCES
IPCKEY 80952
UID 4196
GID 601
PERM 0660
MAXACCESSERS 40
MAXSERVERS 35
MAXSERVICES 75
MAXCONV 10
MAXGTT 20
MASTER SITE1,SITE2
SCANUNIT 10
SANITYSCA
12
BBLQUERY 180
BLOCKTIME 30
DBBLWAIT 6
OPTIONS LAN,MIGRATE
MODEL MP
LDBAL Y
#
*MACHINES
mchn1 LMID=SITE1
TUXDIR="/home/tuxroot"
APPDIR="/home/apps/bank"
ENVFILE="/home/apps/bank/ENVFILE"
TLOGDEVICE="/home/apps/bank/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home/apps/bank/tuxconfig"
TYPE="3B2"
ULOGPFX="/home/apps/bank/ULOG"
wgs386 LMID=SITE2
TUXDIR="/home2/tuxroot"
APPDIR="/home2/apps/bank"
ENVFILE="/home2/apps/bank/ENVFILE"
TLOGDEVICE="/home2/apps/bank/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/home2/apps/bank/tuxconfig"
TYPE="386"
ULOGPFX="/home2/apps/bank/ULOG"
#
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
# For NT/Netware, :bankdb: becomes ;bankdb;
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/home/apps/bank/bankdl1:bankdb:readwrite"
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:/home2/apps/bank/bankdl2:bankdb:readwrite"
*NETWORK
SITE1 NADDR="//mach1.beasys.com:1900"
BRIDGE="/dev/tcp"
NLSADDR="//mach1.beasys.com:1900"
SITE2 NADDR="//mach386.beasys.com:1900"
BRIDGE="/dev/tcp"
NLSADDR="//mach386.beasys.com:1900"
*SERVERS
#
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1 CLOPT="-A -- -T 100"
TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1 CLOPT="-A -- -T 200"
TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2 CLOPT="-A -- -T 600"
TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2 CLOPT="-A -- -T 700"
XFER SRVGRP=BANKB1 SRVID=5
XFER SRVGRP=BANKB2 SRVID=6
ACCT SRVGRP=BANKB1 SRVID=7
ACCT SRVGRP=BANKB2 SRVID=8
BAL SRVGRP=BANKB1 SRVID=9
BAL SRVGRP=BANKB2 SRVID=10
BTADD SRVGRP=BANKB1
BTADD SRVGRP=BANKB2 SRVID=12
AUDITC SRVGRP=BANKB1 SRVID=13 CONV=Y MIN=1 MAX=10
BALC SRVGRP=BANKB1 SRVID=24
BALC SRVGRP=BANKB2 SRVID=25
#
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=N
WITHDRAWAL PRIO=50 ROUTING=ACCOUNT_ID
DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID
TRANSFER PRIO=50 ROUTING=ACCOUNT_ID
INQUIRY PRIO=50 ROUTING=ACCOUNT_ID
CLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_ID
OPEN_ACCT PRIO=40 ROUTING=BRANCH_ID
BR_ADD PRIO=20 ROUTING=BRANCH_ID
TLR_ADD PRIO=20 ROUTING=BRANCH_ID
ABAL PRIO=30 ROUTING=b_id
TBAL PRIO=30 ROUTING=b_id
ABAL_BID PRIO=30 ROUTING=b_id
TBAL_BID PRIO=30 ROUTING=b_id
ABALC_BID PRIO=30 ROUTING=b_id
TBALC_BID PRIO=30 ROUTING=b_id
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID
BUFTYPE="FML"
RANGES="10000-59999:BANKB1,
60000-109999:BANKB2,
*:*"
BRANCH_ID FIELD=BRANCH_ID
BUFTYPE="FML"
RANGES="1-5:BANKB1,
6-10:B
To check the local IPC resources for this configuration, a tmadmin session was started, and the bbsread command was run. The output of bbsread is shown in Listing 15-4.
Listing 15-4 bbsread Output
SITE1> bbsread
IPC resources for the bulleti
board o
machine SITE1:
SHARED MEMORY: Key: 0x1013c38
SEGMENT 0:
ID: 15730
Size: 36924
Attached processes: 12
Last attach/detach by: 4181
This semaphore is the system semaphore
SEMAPHORE: Key: 0x1013c38
Id: 15666
| semaphore | current | last | # waiting |
| number | status | accesser | processes |
|----------------------------------------------|
| 0 | free | 4181 | 0 |
|------------|----------|----------|-----------|
This semaphore set is part of the user-level semaphore
SEMAPHORE: Key: IPC_PRIVATE
Id: 11572
| semaphore | current | last | # waiting |
| number | status | accesser | processes |
|----------------------------------------------|
| 0 | locked | 4181 | 0 |
| 1 | locked | 4181 | 0 |
| 2 | locked | 4181 | 0 |
| 3 | locked | 4181 | 0 |
| 4 | locked | 4181 | 0 |
| 5 | locked | 4181 | 0 |
| 6 | locked | 4181 | 0 |
| 7 | locked | 4181 | 0 |
| 8 | locked | 4181 | 0 |
| 9 | locked | 4181 | 0 |
| 10 | locked | 4181 | 0 |
| 11 | locked | 4181 | 0 |
| 12 | locked | 4181 | 0 |
| 13 | locked | 4181 | 0 |
|------------|----------|----------|-----------|
Note: The display is the same with verbose mode on or off.
To check the current values of the system-wide parameters for this configuration, we started a tmadmin session and ran the bbparms command. The output of bbparms is shown in Listing 15-5.
Listing 15-5 Sample bbparms Output
> bbparms
Bulleti
Board Parameters:
MAXSERVERS: 35
MAXSERVICES: 75
MAXACCESSERS: 40
MAXGTT: 20
MAXCONV: 10
MAXBUFTYPE: 16
MAXBUFSTYPE: 32
IPCKEY: 35384
MASTER: SITE1,SITE2
MODEL: MP
LDBAL: Y
OPTIONS: LAN,MIGRATE
SCANUNIT: 10
SANITYSCAN: 12
DBBLWAIT: 6
BBLQUERY: 180
BLOCKTIME: 30
Note: The display is the same with verbose mode on or off.
