Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Installation   |   Topic List   |   Previous   |   Next   |   Contents

   Installing the BEA Tuxedo System

The BEA Tuxedo System uses the Interprocess Communication (IPC) resources provided by the UNIX operating system.

Note: Equivalent services are available for other operating systems. For example, the BEA Tuxedo system provides an NT service called the BEA Tuxedo IPC Helper, which facilitates inter-process communication on an NT platform.

IPC resources are configured by three sets of tunable parameters that control the following.

Tunable Parameters Named with This Prefix . . .	Control the . . .
SEM	Number of semaphores
MSG	Size of message queues and messages
SHM	Amount of shared memory

The settings for these parameters are application dependent. Most UNIX systems, however, are shipped with default values that are too low for a BEA Tuxedo system application.

The following sections describe the IPC parameters and provide guidelines for configuring them. Because these parameters vary across different versions of the UNIX system, the descriptions provided here are generic. Refer to Platform Data Sheets, for the exact parameter names and defaults for each platform and for information on how to change parameter values. If you change a parameter value, you will need to rebuild the kernel and reboot the operating system, using standard administrative tools. Consult your operating system administrator or the system administrator's guide for your platform for details.

If your BEA Tuxedo application is distributed, the minimum IPC resources must be available on every UNIX platform participating in the application.

Every process that participates in a BEA Tuxedo application requires a semaphore. When the application is booted, the number of semaphores configured in the operating system is checked. The boot fails if the configured number is not high enough.

The following semaphore parameters may need to be adjusted:

SEMMNS

Maximum number of semaphores in the system. The minimum requirement for SEMMNS is

MAXACCESSERS - MAXWSCLIENTS + 13

where MAXACCESSERS is the maximum number of BEA Tuxedo system processes on a particular machine (including servers and native clients) and MAXWSCLIENTS is the maximum number of workstation clients. Both of these parameters are specified in the UBBCONFIG file for the application. For more information about UBBCONFIG, see Creating the Configuration File in Setting Up a BEA Tuxedo Application or the UBBCONFIG(5) reference page in the BEA Tuxedo File Formats and Data Descriptions Reference.

SEMMNI

Maximum number of active semaphore sets. See SEMMSL.

SEMMSL

Maximum number of semaphores per semaphore set. SEMMNI and SEMMSL are commonly chosen so that their product equals SEMMNS. The BEA Tuxedo system does not perform semaphore operations on semaphore sets; however, it attempts to allocate as many semaphores per semaphore set as possible.

SEMMAP

Size of the control map used to manage semaphore sets. SEMMAP should be equal to SEMMNI.

SEMMNU

Number of undo structures in the system. Because an undo structure is needed for each process that can access the Bulletin Board, SEMMNU must be at least as large as SEMMNS.

SEMUME

Maximum number of undo entries per undo structure. The value 1 suffices.

The BEA Tuxedo system uses UNIX system messages and message queues for client/server communication. Examples of such messages are service requests, service replies, conversational messages, unsolicited notification messages, administrative messages, and transaction control messages.

Every MSSQ set (Multiple Servers, Single Queue) of servers and every individual server has a message queue for receiving requests. Every client has its own queue for receiving replies. Servers that specify the REPLYQ parameter also get individual reply queues.

The adjustment of kernel message parameters is important to the proper tuning of an application. Inappropriate values can lead to an inability to boot, or to severe performance degradation.

Several message queue parameters are available to define various characteristics of the queue space.

This parameter. . .	Specifies the . . .
MSGTQL	Total number of outstanding messages that can be stored by the kernel
MSGMNB	Total number of bytes that can be stored on one queue
MSGMAX	Maximum size of an individual message
MSGSEG	Total number of message segments that can be outstanding at one time
MSGSSZ	Size of each segment

If the limit specified by any of these parameters is exceeded, then a blocking condition occurs. There is one exception to this rule: MSGMAX. Messages that exceed 75 percent of MSGMNB, or that are larger than MSGMAX, are placed in a UNIX file. A very small message containing the filename is then sent to the recipient. Because this mode of operation results in a severe reduction in performance, we strongly recommend that you avoid it.

An application deadlock can result if every process is blocked while trying to send a message. For example, when clients fill up the message space with requests, servers that are trying to send replies are blocked. Therefore, no server can read a message and a deadlock results. Occasionally, timeouts can break a deadlock, but no useful work will have been done.

A client that sends its requests with the TPNOREPLY flag is especially troublesome. This practice can fill either individual queues or the system message space, depending on the size of the messages. Such applications may have to implement their own flow control to limit the number of outstanding messages.

To summarize, if clients or servers are blocking on their send operations (requesting services or sending replies), there is potential for trouble. It is usually no problem, though, for a single server request queue to remain full, as long as there is space in the system for more messages on other queues.

There are performance implications to queue blocking conditions, both on the sending side and the receiving side. When waking up blocked processes, the UNIX operating system wakes up all the processes blocked on a particular event, even if only one can proceed. The other processes go back to sleep. This process scheduling overhead can be expensive.

For example, on an empty server request queue on which more than one server (MSSQ) resides, an arriving message wakes up all the idle (blocked) servers on that queue. In the case of a full server request queue, as each request is read by a server, the system wakes up all the blocked clients. Depending on the size of the messages, zero or more clients can place messages on the queue. The rest go back to sleep. Because there may be hundreds of clients in the system, the mass wakeup of all of these clients every time a service request is processed can severely degrade performance.

A properly tuned system rarely fills its queues. Enough slack should be left in the queues to handle the natural variability of the message flow. No exact settings can be recommended. Tuning is very application dependent. The UNIX ipcs(1) command provides a snapshot of the queues so you can determine whether they are full. You can try setting the TPNOBLOCK flag when sending requests. If you do, clients can tell when queues are full, and they can slow down a bit. It might help to increase the scheduling priority of servers with full request queues.

The following message parameters may need to be adjusted.

MSGMNI

Number of unique message queue identifiers. Each process participating in a BEA Tuxedo application on a particular machine typically needs at least one message queue. This number is reduced if MSSQ sets are used, which means that multiple server processes share a single queue. For transaction processing, count an additional queue per server group for TMS processes. Thus, the minimum requirement for MSGMNI can be determined by the following formula.

MSGMNI = MAXACCESSERS + 7
+ (number of servers with REPLYQ)
+ (number of MSSQ sets)
- (number of servers in MSSQ sets)

MSGMAX

Maximum message size in bytes. MSGMAX must be big enough to handle any BEA Tuxedo application running on this machine.

MSGMNB

Maximum message queue length in bytes. This number must accommodate the total size of all messages that are on a queue and have not been taken off by the associated processes. The minimum value for MSGMNB is the value of MSGMAX. Messages longer than 75% of MSGMNB are sent to a file instead of a message queue-a situation that should be avoided because it severely degrades performance.

MSGMAP

Number of entries in the control map used to manage message segments. The value of MSGMAP should be the number of message segments (specified in MSGSEG).

MSGSSZ

Size, in bytes, of a message segment. A message can consist of several such segments. The value of MSGSSZ should be such that a multiple of MSGSSZ is equal to the size (including the BEA Tuxedo system header) of the most commonly sent message. By dividing messages into segments in this way, you can avoid wasting space.

MSGSEG

Number of message segments in the system.

MSGTQL

Total number of outstanding messages that can be stored by the kernel. This is the maximum number of unread messages at any given time.

In the BEA Tuxedo environment, shared memory is used for the Bulletin Board and for the control table of the Workstation Listener process (WSL). An application may also use shared memory for its own purposes.

The following shared memory parameters may need to be adjusted.

SHMMAX

Maximum size, in bytes, of a shared memory segment. This number represents the largest shared memory segment that can be allocated. A process can, however, attach to more than one segment of size SHMMAX.

SHMSEG

Maximum number of shared memory segments per process. For a given configuration, the maximum amount of shared memory to which a process can attach is the product (in bytes) of SHMMAX * SHMSEG. A value between 6 and 15 should be adequate.

SHMMNI

Maximum number of shared memory identifiers in the system. The BEA Tuxedo system requires one identifier per Bulletin Board and an additional identifier if the Workstation Listener (WSL) is running.

SHMMIN

Minimum size, in bytes, of shared memory segment. This parameter should always be set to 1.

Experience with the BEA Tuxedo system has shown that some other UNIX system tunables may need to be set to higher values. These parameters are very application dependent and do not apply to all applications. Platform Data Sheets, includes information on the defaults for each platform and instructions for changing them.

ULIMIT

Maximum file size. ULIMIT needs to be large enough so that you can install the BEA Tuxedo system and build servers. We recommend four megabytes.

NOFILES

Maximum number of open files per process. A BEA Tuxedo server requires a minimum of four file descriptors.

MAXUP

Maximum number of processes per non-super user. The BEA Tuxedo system processes-servers and administrative processes-run with the UID specified in the application's UBBCONFIG file. MAXUP needs to be large enough to allow all of these processes to run.

NPROC

Maximum number of processes (system wide).

NREGION

Number of region table entries to allocate. Most processes have three regions: text, data, and stack. Additional regions are needed for each shared memory segment and each shared library (including text and data) that is attached. However, the region table entry for the text of a "shared text" program is shared by all processes executing that program. Each shared memory segment attached to one or more processes uses another region table entry.

NUMTIM

Maximum number of STREAMS modules that can be pushed by the Transport Layer Interface (TLI). A typical default value is 16; we recommend setting this parameter to at least 256.

NUMTRW

The number of TLI read/write structures to allocate in kernel data space. A typical default value is 16; we recommend setting this parameter to at least 256.

When the BEA Tuxedo system software has been installed and an application configuration file (UBBCONFIG file) is available, use the tmloadcf(1) command to calculate the IPC resources needed to support the application.

• tmloadcf(1) in the BEA Tuxedo Command Reference

• Verifying IPC Requirements on a UNIX System