|
|
|
The DISPLAY IO command provides information about your control file-processing environment.
It is important to remember that while the control file is accessed by all CA MIM address spaces, every CA MIM address space will have unique control file processing data. Therefore, the DISPLAY IO command should be issued on every system in the MIMplex, and examined on a system-by-system basis. Among the information provided is the communication method employed, the number of blocks allocated, the maximum number of blocks used, and the date and time of last format.
A great deal of information is displayed, however, the most important statistics involve the control file cycle rates and transaction processing data. The following illustration shows the DISPLAY IO data:
MIM0039 CONTROL FILE I/O DISPLAY: COMMUNICATION=DASDONLY CURRENT=DASD MODE=DEMAND CYCLES=1 INTERVAL=1.000 FILE=00 NAME=MIM.PRIMARY UNIT=2DC8 TOTAL BLOCKS=1200 MAX USED=547 FREE=1199 BLKSIZE=6144 LAST FORMAT: 2003.119 TOTAL READS=408.463M WRITES=220.841M LAST RESTART AT 07:59:53 ON 2003.119 COUNT: CYC=15.166M BLOCKS READ=57.638M8 WRITTEN=27.639M XACT READ=88.885M PROCESSED=44.093M WRITTEN=26.650M AVG: CYC=0.085302 BLOCKS READ=3.788 WRITTEN=4.120 XACT READ=95.529 PROCESSED=2.907.000 WRITTEN=1.757 RATE: CYC=21.571 BLOCKS READ=165.584 WRITTEN=79.404 XACT READ=2400.309 PROCESSED=120.025 WRITTEN=76.561
The key fields used in the control file tuning analysis phase have been bolded in the preceding illustration. The following describes each of these key fields:
Represents the average control file cycle completion time in seconds. It is comprised of the time required to obtain the control file reserve, read and process any transactions on the file, process any local requests, including writing any transactions, releasing the control file, performing any post file processing, and any wait time before attempting the next control file access.
In our example, control file cycles on this system are taking 85 milliseconds, which is not acceptable for a 3390 DASD control file. In short, the faster the control file cycle time, the more optimized CA MIM performance.
Indicates, on average, how many control file blocks are read from and written to the control file during each control file cycle. Optimally tuned MIMplexes will have a value of less than 1.1 for each of these fields if COMMUNICATION=DASDONLY is specified. If you have a higher value, then it usually means one or more CA MIM address spaces are not accessing the control file frequently enough, and thus transactions destined for those systems are constantly having to be read and re-written by CA MIM on your more active, work-load intense systems. In short, the values of 3.788 and 4.120 as shown in the example are not considered acceptable.
If COMMUNICATION=CTCDASD/CTCONLY/XCF is specified, then it may be acceptable to have BLDS READ and BLKS WRITTEN larger than 1.1. When CA MIM uses a virtual control file, the data is read and written using VCF buffers. The MIMINIT VCFBUFFERSIZE statement, with a default of 32768, determines the size of this buffer. CA MIM attempts to “pack” the maximum number of blocks of data into this VCF buffer, when it reads and writes data to the VCF master system. The amount of data in each block is determined by the MIMINIT BLKSIZE statement, which has a default of 6144.
For example, if the value of AVG BLOCKS READ is 2.0 and MIMINIT BLKSIZE is 6144, then CA MIM usually reads 12288 bytes of data during each control file transaction.
However, if the value of AVG BLOCKS READ is 7.0 and MIMINIT BLKSIZE is 6144, then CA MIM usually reads 43008 bytes of data during each control file transaction.
If the value of VCFBUFFERSIZE is 32768, then you should increase the size of this buffer, because CA MIM is not able to fit all of the data into one VCF buffer, and requires multiple VCF buffers for each control file access. This increases the number of I/Os required to complete each control file cycle. A more appropriate value for VCFBUFFERSIZE in this example would be 44000.
This field represents the number of control file cycles per second. The frequency of control file cycles is driven by either of two events:
CA MIM on a system having a large amount of managed enqueue requests, will access the control file more frequently than CA MIM on a system that has very little managed enqueue requests. If you have a MIMplex comprised of systems running a range of heavy to light enqueue workloads, then CA MIM address spaces on each system will be accessing the control file at different frequencies. In other words, CA MIM on a production system may perform control file cycles at a rate of 25 times per second, while CA MIM on a test system may perform a control file cycle only one time per second. Severely disproportionate control file access rates by CA MIM on different systems will elongate individual control file cycle times, and in turn degrade CA MIM transaction processing times. Acceptable values for this field vary from site to site depending upon a number of factors. If this value is too high, then CA MII address space CPU consumption may increase; if this value is too low, then MIMplex throughput may suffer.
In general, most sites will not want this value to be more than 30 on any system. Some sites, however, use XES control files with average cycle rates as high as 45 control file cycles per second with great success. The number of control file cycles per second can be increased or decreased on a system-by-system basis. Control File Tuning: Implementation in this chapter examines how this can be done.
These fields represent the average number of transactions read, and the number of transactions processed by this system, during each control file cycle. In CA MIM Transactions in this chapter it is mentioned that CA MIM transactions remain in the control file for a very short period of time. Once a transaction has been read and processed by all CA MIM address spaces in the complete, that transaction is removed from the control file.
During every control file cycle, the CA MIM address space must read in every transaction from the control file and examine the routing mask to determine if the transaction needs to be processed by this system. If the transaction was already processed by this system during a previous control file cycle, then that transaction is written back out to the control file along with new transactions that this system needs to route to all external systems. The process of having to constantly read, but not process the transactions of other systems, causes the Transactions Read to Processed ratio to increase.
Ideally, you want every CA MIM address space to process at least 1 out of every 10 transactions it reads from the control file. Therefore, the Transactions Read to Processed ratio should be within 10 to 1. This ratio can be calculated by dividing the Transactions Read value by the Transactions Processed value. In a MIMplex having CA MIM address spaces performing control file cycles at significantly disproportionate rates, you will find the Transactions Read to Processed ratio is more than 10 to 1 on some systems. The example indicates that, on average, during each control file cycle, this system reads 2400 transactions from the control file, of which only 120 transactions are destined for this system. This means that during every control file this system is reading 2280 transactions that are not for this system. The Transactions Read to Processed ratio in the example is roughly 20 to1, which is not acceptable. Increasing or decreasing the number of control file cycles per second on certain systems will correct this problem.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |