The following sections describe the interprocess communication (IPC) parameters on a UNIX system and provide guidelines for configuring them:
On a UNIX system, the BEA Tuxedo system uses the IPC resources provided by the UNIX operating system, which are controlled by the following three sets of tunable parameters.
The settings for these parameters are application-dependent. Most UNIX systems are shipped with default values that are too low for a BEA Tuxedo application.
Because the IPC parameters vary across different versions of the UNIX system, the descriptions provided in the following sections are generic. For the exact parameter names and defaults for each platform and for information on how to change parameter values, see BEA Tuxedo 10.0 Platform Data Sheets. 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.
In the BEA Tuxedo environment, shared memory is used for the bulletin board and the control table of the workstation listener (WSL) and the IIOP listener (ISL) processes. An application may also use shared memory for its own purposes.
The following shared memory parameters may need to be adjusted:
SHMMAX * SHMSEG. A value between 6 and 15 should be adequate.
Every process that participates in a BEA Tuxedo application requires a semaphore. A semaphore is a hardware or software flag used to prevent processes from accessing the same shared memory space at the same time. When a process has control of a shared memory resource, all other processes are locked out of the shared memory resource until the process releases the resource.
When the BEA Tuxedo application is booted, the underlying BEA Tuxedo system checks the number of semaphores configured in the operating system. If the configured number is not high enough, the boot fails.
The following semaphore parameters may need to be adjusted:
MAXACCESSERS - MAXWSCLIENTS + 13where
MAXACCESSERSis the maximum number of BEA Tuxedo system processes on a particular machine (including servers and native clients) and
MAXWSCLIENTSis the maximum number of BEA Tuxedo remote clients. Both of these parameters are specified in the
UBBCONFIGfile for the application. For more information about
UBBCONFIG, see “Creating the Configuration File” in Setting Up a BEA Tuxedo Application or
UBBCONFIG(5)in the File Formats, Data Descriptions, MIBs, and System Processes Reference.
SEMMSLare 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.
undostructures in the system. Because an
undostructure is needed for each process that can access the bulletin board,
SEMMNUmust be at least as large as
SEMMNS. (The UNIX operating system uses
undostructures to unlock semaphores held by processes that die unexpectedly.)
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 Multiple Servers, Single Queue (MSSQ) set 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, as indicated in the following table.
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:
MSGMNIcan be determined by the following formula:
MSGMNI = MAXACCESSERS + 7
+ (number of servers with REPLYQ)
+ (number of MSSQ sets)
- (number of servers in MSSQ sets)
MSGMAXmust be big enough to handle any BEA Tuxedo application running on this machine.
MSGMNBis the value of
MSGMAX. Messages longer than 75% of
MSGMNBare sent to a file instead of a message queue—a situation that should be avoided because it severely degrades performance.
MSGMAPshould be the number of message segments (specified in
MSGSSZshould be such that a multiple of
MSGSSZis 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.
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. BEA Tuxedo 10.0 Platform Data Sheets includes information on the defaults for each platform and instructions for changing them.
ULIMITneeds to be large enough so that you can install the BEA Tuxedo system and build servers. We recommend 4 MB.
UIDspecified in the application’s
MAXUPneeds to be large enough to allow all of these processes to run.