![]() |
![]() |
![]() |
![]() |
![]() |
For more information about monitoring Oracle Tuxedo applications, see “Monitoring a Running System” in the Administering an Oracle Tuxedo Application at Run Time.Table 4‑1 describes when to use MSSQ sets with Oracle Tuxedo servers.
Table 4‑1 When and When Not to Use MSSQ Sets
Note: On Oracle Tuxedo CORBA systems, system-controlled load balancing is enabled automatically. You cannot disable load balancing by specifying LDBAL=N.To determine how to assign load factors (located in the SERVICES section), run an application continually and calculate the average time it takes for each service to be performed. Assign a LOAD value of 50 (LOAD=50) to any service that requires the average amount of time that you calculated. Any service taking longer to execute than the calculated average should have a LOAD>50. Any service taking less to execute than the calculated average should have a LOAD<50.A LOAD factor is assigned to each service performed, which keeps track of the total load of services that each server has performed. Each service request is routed to the server with the smallest total load. The routing of that request causes the server's total to be increased by the LOAD factor of the service requested.You can also apply LOAD factors to interfaces. For more information about LOAD factors, see “Creating a Configuration File” in the Administering an Oracle Tuxedo Application at Run Time.
1. Edit the application’s UBBCONFIG file using a text editor.
2. In the GROUPS section, specify the names of the groups you want to configure.
3.
The MIN and MAX parameters determine the degree to which a given server application can process requests on a given interface in parallel. During run time, the system administrator can examine resource bottlenecks and start additional server processes, if necessary, thereby scaling the application. For more information, see “Monitoring a Running Application” in the Administering an Oracle Tuxedo Application at Run Time.
Note: The MAX parameter controls the maximum number of instances. However, Oracle Tuxedo does not spawn instances automatically. The system will automatically start up to the specified MIN number of instances. Between MIN and MAX, the system administrator will need to spawn new instances manually. Once MAX is reached, an error will be returned by tmboot, tmadmin, or the TMIB API.To enable the use of threads by a multithreaded server when interoperating with the Oracle XA database software, you must add Threads=true to the OPENINFO parameter in the GROUPS section of the UBBCONFIG file, as shown in Listing 4‑1. For more information, see the Oracle XA online documentation.Listing 4‑1 Adding Threads=true to the OPENINFO ParameterThe following parameters are used configure multithreaded CORBA servers. These parameters are set in UBBCONFIG file:
Note: While the MAXOBJECTS parameter does not specifically apply to threads, you may want to increase this parameter because multithreaded applications have the potential to activate more objects at any point in time than single-threaded applications.
• “Creating the Configuration File” and “How to Configure the Oracle Tuxedo System to Take Advantage of Threads” in Setting Up an Oracle Tuxedo Application.
• “Setting the MAXACCESSERS, MAXSERVERS, MAXINTERFACES, and MAXSERVICES Parameters” in Administering an Oracle Tuxedo Application at Run Time.You can exert significant control over the flow of data in an application by assigning priorities to Oracle Tuxedo Interfaces using the PRIO parameter. For a CORBA application running on an Oracle Tuxedo system, you can specify the PRIO parameter for each interface named in the INTERFACES section of the application’s UBBCONFIG file.You can also dynamically change a priority with the tpsprio() call. Only preferred clients should be able to increase the interface priority. In a system on which servers perform interface request, the server can call tpsprio() to increase the priority of its interface so the user does not wait in line for every interface request that is required.The PRIO parameter should be used carefully. Depending on the order of messages on the queue (for example, A, B, and C), some (such as A and B) will be dequeued only one in ten times. This means reduced performance and potential slow turnaround time on the service.The characteristics of the PRIO parameter are as follows:
• Functional similarity—if some services are similar in their role in the application, you can bundle them in the same server. The application can offer all or none of them at a given time. An example is the bankapp application, in which the WITHDRAW, DEPOSIT, and INQUIRY services are all teller operations. Administration of services becomes simpler.Performance options were added to Oracle Tuxedo in release 8.0. These options enable you to turn off specific features in the Oracle Tuxedo infrastructure. You should turn off these features only if they are not required by your CORBA or ATMI applications. Table 4‑3 describes these options.
Table 4‑3 Performance Options For more information about these options, see Administering an Oracle Tuxedo Application at Run Time and UBBCONFIG(5) and TM_MIB(5), and tuxenv(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference. Turning off threads (TMNOTHREADS) You use the tuxenv(5) to set this option. For more information, see Administering an Oracle Tuxedo Application at Run Time and tuxenv(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference. You set this option in the RESOURCES section of the UBBCONFIG file. For more information, see Administering an Oracle Tuxedo Application at Run Time and OPTION in the RESOURCES section of UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference. For more information about the NO_XA option, see Administering an Oracle Tuxedo Application at Run Time and UBBCONFIG(5) and TM_MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.The MAXDISPATCHTHREADS parameter determines the maximum number of concurrently dispatched threads that each server process can spawn. When specifying this parameter, consider the following:
• The value for MAXDISPATCHTHREADS determines the maximum size that the thread pool can grow to be, as it increases in size to accommodate incoming requests.
• The default value for MAXDISPATCHTHREADS is 1. If you specify a value greater than 1, the system creates and uses a special dispatcher thread. This dispatcher thread is not included in the number of threads determining the maximum size of the thread pool.
• Specifying a value of 1 for the MAXDISPATCHTHREADS parameter indicates that the server application should be configured as a single-threaded server. A value greater than 1 indicates that the server application should be configured as a multithreaded server.
• The value you specify for the MAXDISPATCHTHREADS parameter must not be less than the value you specify for the MINDISPATCHTHREADS parameter.
• The operating system resources limit the maximum number of threads that can be created in a process. MAXDISPATCHTHREADS should be less than that limit, minus the number of application managed threads that your application requires.The value of the MAXDISPATCHTHREADS parameter affects other parameters. For example, the MAXACCESSORS parameter controls the number of simultaneous accesses to the Oracle Tuxedo system, and each thread counts as one accessor. For a multithreaded server application, you must account for the number of system-managed threads that each server is configured to run. A system-managed thread is a thread that is started and managed by the Oracle Tuxedo software, as opposed to threads started and managed by an application. Internally, Oracle Tuxedo manages a pool of available system-managed threads. When a client request is received, an available system-managed thread from the thread pool is scheduled to execute the request. When the request is completed, the system-managed thread is returned to the pool of available threads.Use the MINDISPATCHTHREADS parameter to specify the number of server dispatch threads that are started when the server is initially booted. When you specify this parameter, consider the following:
• The value for MINDISPATCHTHREADS determines the initial allocation of threads in the thread pool.
• The separate dispatcher thread that is created when MAXDISPATCHTHREADS is greater than 1 is not counted as part of the MINDISPATCHTHREADS limit.
• The value you specify for MINDISPATCHTHREADS must not be greater than the value you specify for MAXDISPATCHTHREADS.
• The default value for MINDISPATCHTHREADS is 0.The MAXACCESSERS, MAXOBJECTS, MAXSERVERS, MAXINTERFACES, and MAXSERVICES parameters increase semaphore and shared memory costs, so you should choose the minimum value that satisfies the needs of the system. You should also allow for the variation in the number of clients accessing the system at the same time. Defaults may be appropriate for a generous allocation of IPC resources. However, it is prudent to set these parameters to the lowest appropriate values for the application.For multithreaded servers, you must account for the number of threads that each server is configured to run. The MAXACCESSERS parameter sets the maximum number of concurrent accessors of an Oracle Tuxedo system. Accessors include native and remote clients, servers, and administration processes. For more information on setting the MAXACCESSERS parameter, see “MAXDISPATCHTHREADS” on page 4‑11.You should increase the value of the MAXGTT parameter if the product of multiplying the number of clients in the system times the percentage of time they are committing a transaction is close to 100. This may require a great number of clients, depending on the speed of commit. If you increase MAXGTT, you should also increase TLOGSIZE accordingly for every machine. You should set MAXGTT to 0 for applications that do not use distributed transactions.You can limit the number of buffer types and subtypes allowed in the application with the MAXBUFTYPE and MAXBUFSTYPE parameters, respectively. The current default for MAXBUFTYPE is 16. Unless you are creating many user-defined buffer types, you can omit MAXBUFTYPE. However, if you intend to use many different VIEW subtypes, you may want to set MAXBUFSTYPE to exceed its current default of 32.If a system is running on slower processors (for example, due to heavy usage), you can increase the timing parameters: SANITYCAN, BLOCKTIME, and individual transaction timeouts. If networking is slow, you can increase the value of the BLOCKTIME, BBLQUERY, and DBBLWAIT parameters.Table 4‑4 describes the system parameters available for tuning an application.
Table 4‑4 System Parameters for Application Tuning Use MAXBUFTYPE only if you create eight or more user-defined buffer types. The values of different system parameters determine IPC requirements. You can use the tmboot -c command to test a configuration’s IPC needs. The values of the following parameters affect the IPC needs of an application:
•
• RQADDR (that allows MSSQ sets to be formed)
• Table 4‑5 describes the system parameters that affect the IPC needs of an application.
Table 4‑5 Tuning IPC Parameters Number of message queues is almost equal to MAXACCESSERS + the number of servers with reply queues (the number of servers in MSSQ set + the number of MSSQ sets). While MAXSERVERS, MAXSERVICES, MAXGTT, and the overall size of the ROUTING, GROUP, and NETWORK sections affect the size of shared memory, an attempt to devise formulas that correlate these parameters can become complex. Instead, simply run tmboot -c or tmloadcf -c to calculate the minimum IPC resource requirements for your application. For more information about monitoring Oracle Tuxedo applications and measuring traffic, see “Monitoring a Running System” in the Administering an Oracle Tuxedo Application at Run Time.For example, in Tuxedo applications, when tpsvrinit() is invoked at boot time, you can initialize a global counter and record a starting time. Subsequently, each time a particular service is called, the counter is incremented. When the server is shut down by invoking the tpsvrdone() function, the final count and the ending time are recorded. This mechanism allows you to determine how busy a particular service is over a specified period of time.
Note: Suppose Client 1 requires 4 seconds to print to the screen. Calls to time(2) determine that the tpcall to service A is the culprit with a 3.7 second delay. Service A is monitored at the top and bottom and takes 0.5 seconds. This implies that a queue may be clogged, which was determined by using the pq command.On the other hand, suppose service A takes 3.2 seconds. The individual parts of Service A can be bracketed and measured. Perhaps Service A issues a tpcall to Service B, which requires 2.8 seconds. It should then be possible to isolate queue time or message send blocking time. Once the relevant amount of time has been identified, the application can be retuned to handle the traffic.On UNIX systems, the sar(1) command provides valuable performance information that can be used to find system bottlenecks. You can use the sar(1) command to:Table 4‑6 describes the sar(1) command options.
Table 4‑6 sar(1) Command Options
Note: Some UNIX platforms do not provide the sar(1) command, but offer equivalent commands instead. BSD, for example, offers the iostat(1) command. Sun Microsystems, Inc. offers perfmeter(1).