![]() |
![]() |
![]() |
![]() |
![]() |
On a UNIX system, the Oracle Tuxedo system uses the IPC resources provided by the UNIX operating system, which are controlled by the tunable parameters listed in Table D‑1.
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 Oracle Tuxedo 12c Release 2 (12.2.2) 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.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.Every process that participates in an Oracle 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.where MAXACCESSERS is the maximum number of Oracle Tuxedo system processes on a particular machine (including servers and native clients) and MAXWSCLIENTS is the maximum number of Oracle Tuxedo remote clients. Both of these parameters are specified in the UBBCONFIG file for the application. For more information about UBBCONFIG, see Creating the Configuration File or UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.Maximum number of semaphores per semaphore set. SEMMNI and SEMMSL are commonly chosen so that their product equals SEMMNS. The Oracle Tuxedo system does not perform semaphore operations on semaphore sets; however, it attempts to allocate as many semaphores per semaphore set as possible.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. (The UNIX operating system uses undo structures to unlock semaphores held by processes that die unexpectedly.)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.Several message queue parameters are available to define various characteristics of the queue space, as indicated in Table D‑2.
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.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.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.Number of unique message queue identifiers. Each process participating in an Oracle 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 transaction manager server (TMS) processes. Thus, the minimum requirement for MSGMNI can be determined by the following formula:Maximum message size in bytes. MSGMAX must be big enough to handle any Oracle Tuxedo application running on this machine.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.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).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 Oracle 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 Oracle 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. Oracle Tuxedo 12c Release 2 (12.2.2) Platform Data Sheets includes information on the defaults for each platform and instructions for changing them.Maximum file size. ULIMIT needs to be large enough so that you can install the Oracle Tuxedo system and build servers. We recommend 4 MB.Maximum number of processes per non-superuser. The Oracle 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.