|
|
|
|
|
|
After your application is up and running, as an administrator you must ensure that it meets the performance, availability, and security standards of your company. 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 provide 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, correctly, and securely.
This chapter includes 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 data repositories:
Where the Data Resides
This chapter describes the data stored in the UBBCONFIG
file and in the Bulletin Board, and provides instructions for monitoring that data. For a description of the log files, see Monitoring Log Files.
The administrative data provided by your WLE or BEA TUXEDO system lets you monitor a multitude of potential trouble areas on your system. For example, this data lets you:
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.
There are two types of administrative data available on every running WLE and BEA TUXEDO system: static and dynamic.
Static data 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) that is allocated to your system on your local machine. Static data is kept in the UBBCONFIG
file and in the Bulletin Board.
At times you will need to check the static data about your configuration. For example:
Static and Dynamic Data
Static Data
Dynamic data 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 and in JavaServers and the Active Object Map (AOM).
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.
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 UBBCONFIG
file when necessary. Both the WLE and BEA TUXEDO systems provide the following ways to monitor this data, as shown in this table.
Monitoring Methods
You Can Use the . . . |
By . . . |
For Instructions, See . . . |
|---|---|---|
The preferred method depends on your level of experience and the type of information you need to view.
If you are an experienced administrator (and have shell programming expertise), you may prefer to write programs that automate your most frequently run commands.
If you are not an experienced UNIX user, you may be most comfortable using the Web-based GUI.
If you examine the RESOURCES
section of the UBBCONFIG
file using the tmadmin
command, you can see only the current values; the defaults are not displayed.
If you decide to monitor your system at run time using the tmadmin
command interpreter, continue reading; this chapter describes tmadmin
and explains how to use it.
The tmadmin
command is an interpreter for a large set of commands that let you view and modify a Bulletin Board and its associated entities.
Note:
tmadmin
is supported on UNIX and Windows NT platforms.
This section provides step-by-step information about:
Using the tmadmin Command Interpreter
Detailed instructions for individual tasks are provided in later sections of this chapter.
How might you want to use 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 [operating_mode_option
]
>
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 (-r ), or configuration mode (-c ).
No bulletin board exists. Entering boot mode
>
Not all tmadmin commands are available on every machine at all times. Which commands are available depends on several factors:
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. You can also 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:
$ tmadmin
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 metacommands.
Note: The tables and examples in this chapter include the abbreviated forms of the tmadmin command names.
Use This Command |
Or its Abbreviation |
To |
|---|---|---|
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, JDBC connection pool name, 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.
After 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
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)
Conn Pool Name: (not set)
Blocks: 1000
Offset: 0
Path: (not set)
>
default -parameter new_value
For example, to change the default of the service name to "teller," enter the following command:
default -s teller
default - parameter *
For example, to unset the default for the service name (specified with the -s argument), enter the following command:
default -s *
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 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.
To run the tmadmin
commands:
Optional and Required Arguments
Running tmadmin Commands
tmadmin_command -v
For example: bbparms -v
tmadmin_command -t
For example: printjdbcconnpool -t
quit
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:
Example: Output from tmadmin Commands
Note: For a list of all 50 tmadmin commands, see the tmadmin (1) reference page in the BEA TUXEDO Reference Manual.
The following output from the printqueue
command lets you check the distribution of work in the bankapp
application.
printqueue [qaddress]
printqueue Output
tmadmin - Copyright © 1996-1999 BEA Systems, Inc.
Portions* Copyright 1986-1997 RSA Data Security, Inc.
>printqueue
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:
In the Column Labeled . . . |
You See . . . |
|---|---|
|
The symbolic queue name (set to either the RQADDR
parameter of UBBCONFIG
or a randomly chosen value)
|
|
The following (verbose) output from the printconn
command shows that the client process has:
printconn Data
printconn [-m machine]
tmadmin - Copyright © 1996-1999 BEA Systems, Inc.
> echo
Echo now on.
> v
Verbose now on.
> pc
Originator
Group/pid: Client/29704
LMID: SITE1
Sends: 0
Subordinate
Group/server id: Group1/2
LMID: SITE1
Sends: -
Service: TOUPPER1
Originator
Group/pid: Client/29704
LMID: SITE1
Sends: 0
Subordinate
Group/server id: Group1/2
LMID: SITE1
Sends: -
Service: TOUPPER2
This section shows the output from the following procedure.
printnet Command Output
printnet [-m machine_list]
tmadmin - Copyright © 1996-1999 BEA Systems, Inc. All rights reserved.
> echo
Echo now on.
> pnw
SITE1 Connected To: msgs sent msgs received
SITE2 100103
SITE2 Connected To: msgs sent msgs received
SITE1 104 101
> pnw
SITE1 Connected To: msgs sent msgs received
Could not retrieve status from SITE2
>
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 both terse and verbose modes:
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 © 1996-1999 BEA Systems, Inc.
Portions* Copyright 1986-1997 RSA Data Security, Inc.
All rights reserved.
> printtrans
>> 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
>
The printjdbcconnpool
command reports statistics on JDBC connection pools such as the maximum number of connections per pool, the number of connections in use, the number of clients waiting for a connection, and the high-water mark or highest number of connections used for a pool.
This section shows the output produced by running the printjdbcconnpool
command in terse and verbose modes. In terse mode the maximum pool size, the current pool size, and the number of connections currently in use are shown. In verbose mode the number of clients waiting and the high-water mark are also shown.
>printjdbcconnpool The following is the verbose mode output for a single connnection pool:
Pool Name: Pool2 This section presents a sample configuration for a multiprocessor (MP) version of the 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.
For this case study, we will use the configuration defined in the UBBCONFIG
file shown in Listing 15-3.
Listing 15-3
UBBCONFIG File for bankapp (MP Version)
#Copyright (c) 1997, 1998 BEA Systems, Inc. *RESOURCES 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
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
Note:
The display is the same with verbose mode on or off.
printjdbcconnpool Command Output
Pool Name Grp Name Srv Id Size Max Size Used
----------- ---------- ------ ---- -------- ----
ejbPool J_SRVGRP 101 1 15 0
Pool2 J_SRVGRP 102 10 30 3
Group ID: J_SRVGRP
Server ID: 102
Driver: (none)
URL: (none)
Database Name: Db
User: leia
Host: SITE1
Password: mypwd
Net Protocol: odbc
Port: 120
Props: (none)
Enable XA: No
Create On Startup: Yes
Pool Size: 10
Maximum Size: 30
Capacity increment: 3
Allow shrinking: Yes
Shrink interval: 10 min(s)
Login delay: 1 sec(s)
Connections in use: 3
Connections awaiting: 0
HWM connections in use: 5
Test table: testtable
Refresh interval: 20 sec(s)
Test conn OnReserve: Yes
Test conn OnRelease: NoCase Study: Monitoring Run-time bankapp
Configuration File for bankapp
#All rights reserved
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:BANKB2,
Output from Checking the Local IPC Resources
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 |
|------------|----------|----------|-----------|
Output from Checking System-wide Parameter Settings
Bulletin Board Parameters:
MAXSERVERS: 50
MAXSERVICES: 100
MAXACCESSERS: 50
MAXGTT: 100
MAXCONV: 1
MAXBUFTYPE: 16
MAXBUFSTYPE: 32
MAXOBJECTS: 1000
MAXINTERFACES: 150
IPCKEY: 35384
MASTER: SITE1,SITE2
MODEL: MP
LDBAL: Y
OPTIONS: LAN,MIGRATE
SCANUNIT: 10
SANITYSCAN: 12
DBBLWAIT: 6
BBLQUERY: 30
BLOCKTIME: 6
Shared Memory ID: 0
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|