| Sun Mainframe Transaction Processing Troubleshooting and Tuning Guide |    
|
| Sun Mainframe Transaction Processing Troubleshooting and Tuning Guide |
|
| C H A P T E R 12 |
|
Performance |
This chapter describes the factors that affect Sun MTP in a production environment. Topics include:
This section describes the Sun MTP configuration factors that affect the performance of your application.
Recovery can affect performance based on:
When recovery is enabled, your application's performance might be affected by the recovery method you select.
The file recovery method requires a large number of I/O operations. This overhead can slow down the region while recovery is active.
The Native Recovery File System (NRFS) method requires about half as many I/O operations as the file recovery method, usually resulting in less degradation during recovery.
Refer to the Sun Mainframe Transaction Processing Software Configuration Guide for guidelines on configuring recovery.
Long running batch programs can produce large recovery files. Sun MTP maintains before images in a circular file. When the end of the file is reached, the before images start again at the beginning of the file. Sun MTP ensures that no before image is overwritten if a program or transaction is still active. Instead, when an active before image is about to be overwritten, the program or transaction that wrote the before image is terminated. Therefore, the recovery file must be large enough to contain all records updated by any one program or transaction, as well as any records updated by any other programs and transactions that are also active.
Refer to the Sun Mainframe Transaction Processing Software Developer's Guide for information about recovery and batch processing.
Your choice of running with semaphores or mutual exclusion locks (mutexes) can affect system performance. By default, Sun MTP runs with semaphores. If you are experiencing poor performance, you can enable mutexes instead of using semaphores. The -j option to unikixmain enables mutexes.
The number of transaction servers you configure and the frequency with which they recycle can affect performance.
Check the unikixmain.log file to see if there are messages about exiting and restarting that can help in solving these problems.
Also, be aware that each of the system transactions that access the Development System, such as CMNU and CTBL, takes control of a transaction server, which is not released until you exit the transaction.
You define the number of transaction servers in the VCT, and specify the maximum number of background tasks, the maximum batch jobs, and the number of debug terminals that can run in your region. Refer to the Sun Mainframe Transaction Processing Software Configuration Guide for configuration guidelines.
Typically, the number of background tasks should not exceed 50 percent of the number of transaction servers. However, if the application depends on STARTing background transactions (Transient Data TRIGGERed or STARTed transactions) frequently, you can set a value that is 75 percent of the value set for transaction servers. If you configure too high a value for background tasks, online users will experience poor performance because most of the transaction processors are performing background tasks.
The total number of batch jobs should not exceed 50 percent of the number of transaction servers. If you configure too high a value, online users will experience poor performance because most of the transaction processors are performing batch jobs.
The sum of the maximum background tasks and the maximum batch jobs must be equal to or less than the number of transaction servers. If they are not, an error message is displayed, and you cannot save the VCT until you change the value(s).
If the number of debug terminals you specify in the VCT is greater than the total number of transaction servers, online users might experience poor performance because most of the transaction processors are performing debugging tasks.
It is normal for transaction servers to exit and restart. However, if the transaction servers are recycling too frequently, the memory threshold and maximum core values for the region might not be configured properly. Try increasing the -M t value while not increasing the -M c value; always increase the -M t value in multiples of 2 Mbytes. Refer to the Sun Mainframe Transaction Processing Software Configuration Guide for information about using these options to adjust the shared memory attach location.
In some cases, if you run a CINI or CEMT...NEWCOPY transaction to recycle the transaction servers and some transaction servers do not recycle, messages similar to the following are written to the unikixmain.log file:
If there are many of these messages in the log file, the recycle might not have taken place because a transaction server was waiting for a socket connection, or a conversational transaction has not completed. Make sure these types of transactions are not running before recycling with the CINI or CEMT...NEWCOPY transactions.
If the region slows down after running for a few days, read Transaction Servers and make sure this problem is not due to the configuration of your transaction servers.
Usually, this problem occurs if there are not enough shared memory segments. The kixdump -s validate command provides details on how the region acquired additional shared memory. If there are more than five additional allocations of shared memory, this might be the cause of the degradation.
1. Examine your applications to determine how much shared memory is allocated.
2. Restart the region using unikixmain with the -S option to allocate more shared memory.
Experiment with several different values to find the one that eliminates the degradation.
3. If this does not solve the problem, use the kixsnap utility to capture snapshots of the system and send them to your authorized service provider.
Refer to the Sun Mainframe Transaction Processing Software Reference Guide for a description of kixsnap.
For a detailed description of how Sun MTP uses shared memory, as well as guidelines for configuring shared memory on your region, refer to the Sun Mainframe Transaction Processing Software Configuration Guide.
This section describes VSAM file configuration factors that can affect performance.
Each transaction server process in Sun MTP opens files that are needed by the application and files that are used internally. The File Control Table (FCT), Destination Control Table (DCT), and the Journal Control Table (JCT) define which application files to open. See the Sun Mainframe Transaction Processing Software Reference Guide for information about the tables.
Each Sun MTP application file requires one or more physical files. These files are listed in the following table.
|
1 + the number of segments of the file
|
||
Each transaction, recovery and main server process opens all the files listed in TABLE 12-1. The operating system limits each server process to the maximum number of files it can open. This tunable kernel parameter is NOFILES. If the number of files allocated to a single transaction, recovery or main server is greater than the system limit, the server fails when it tries to open all the files.
In addition, the tunable kernel parameter NFILES specifies a maximum total number of open files in the system. To determine an approximate number of open files for a Sun MTP server, use this calculation:
NFILES = Number of files from the table * (number of transaction servers + 2)
+ 3 for log and dump files
If other Sun MTP servers or other processes are resident on the same system, you must add the file requirements for those servers or processes to the open file requirements.
Although block size can affect application performance, the Sun MTP software does not require a file system with a specific block size. For optimum performance, however, VSAM files should reside on a file system with the same block size as the Sun MTP block size.
The -b blksize option to unikixmain specifies the system-wide VSAM block size as kilobytes (Kbytes). The possible values are 4, 8, 16, or 32. The default block size is 4 Kbytes. This option applies only if there is no VSAM catalog. If the catalog exists, the VSAM block size is automatically equal to the block size of the catalog. To change the block size, refer to the Sun Mainframe Transaction Processing Software Administrator's Guide.
|
Note - The block size of files must be the same as the block size of the VSAM catalog or they cannot be opened. |
Temporary storage can influence your system's performance. You can control how temporary storage is managed by using the -T option to unikixmain. The -T option has two arguments.
Refer to the Sun Mainframe Transaction Processing Software Reference Guide for a description of unikixmain.
When running applications, you might encounter performance degradation as a result of I/O bottlenecks. I/O bottlenecks can occur if your VSAM files are very large or if the journal buffer size you selected for Sun MTP accounting is too small.
I/O bottlenecks can develop if VSAM files are very large. The Sun MTP spanned file facilities allow you to allocate a large file across multiple file systems. You can specify up to eight segments for each KSDS file.
Sun MTP writes the data using the block size configured at startup. Improved throughput should result, because access to records from transactions is not limited by the throughput of a single device.
If you use a journal for Sun MTP accounting, use a buffer size of 32 Kbytes. This buffers the accounting records (approximately .5 Kbytes each) in memory until the buffer grows to 32 Kbytes, at which time the buffer is flushed to disk. The 32 Kbyte buffer size reduces file I/O and improves performance.
If your application uses VSAM files that are configured without recovery, you can improve I/O throughput by using the VSAM cache write feature, which enables the Sun MTP system to defer physical writes to VSAM files by holding them in system cache. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for information about using the caching feature.
If you have a high number of VSAM datasets and periodically get No unused buffers system messages, there might be a lot of active transactions using many different files. Implement any of these suggestions to resolve this problem
If you convert the block size, you must export the VSAM catalog and then import it. Refer to the Sun Mainframe Transaction Processing Software Administrator's Guide for more information.
By default, Sun MTP reserves half the buffer pool for VSAM index blocks; the remainder is used for VSAM data blocks.
The -I bufprcnt option to unikixmain enables you to alter the way the VSAM buffer pool is managed. This parameter, a value between 25 and 75, specifies the percentage of the buffer pool to reserve for VSAM index blocks.
The way your programs are designed can affect performance.
The use of conversational transactions in your applications can cause performance problems. A conversational transaction is one in which dialog with the user (typically a SEND/RECEIVE sequence) is carried on while the transaction is active. This differs from a pseudo-conversational transaction in which there is no interaction with the user during the course of the transaction. Typically, a pseudo-conversational transaction ends with a SEND followed by a RETURN TRANSID. While the user types in a response, the transaction is not active. When the user presses Enter or a PF key, a new instance of the transaction specified by the TRANSID is initiated.
When using the Sun MTP recovery capability, there are important design implications for conversational transactions. When the recovery capability is turned on, a transaction retains control of any VSAM record it has modified until the end of the transaction or until a syncpoint. This means that a conversational transaction could retain control of a record for many seconds or minutes while it is waiting for a response from the user. This is true even though the record was already written. In a system without recovery capability, the record becomes available to other transactions at this point.
Another design issue results from the fact that the maximum time span of a transaction becomes unbounded if the transaction requires a response from a user before it completes. The update might appear to the user to be complete, but it is not. Until the transaction completes, that update is not committed to the database. If the transaction fails many minutes later, the user might not realize that the update was rolled back.
You can prevent these problems by either avoiding conversational transactions entirely, or, in the case of systems that are already written conversationally, by adding a SYNCPOINT command just prior to any RECEIVE command occurring at a point where a record could be held.
Excessive swapping or paging can degrade system performance. If your operating system is swapping or paging excessively, you might need to reduce the number of transaction servers and the memory threshold value. If your application requires these values, you might need to increase real system memory.
| Sun Mainframe Transaction Processing Troubleshooting and Tuning Guide | 816-5333-11 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
To Resolve the Shared Memory Problem