MQSeries Application Structure Help

Normally, messages will reside in an MQSeries application structure only long enough for the exploiting application to retrieve them. However, if the exploiting application suffers an outage that prevents it from retrieving messages from the structure, the structure must be large enough to retain any messages that might be written to it for the duration of the outage. You must therefore consider (1) the number of queues that map to the structure, (2) the average put rate for each queue (i.e., the rate at which messages are written to the structure), and (3) the maximum outage duration to be tolerated.

Messages greater than 63KB (64512 bytes) reside in Db2 LOB structures rather than in the application structure itself. The application structure nevertheless requires some amount of storage for each such message, so queues for which the average message size exceeds 63KB receive special treatment in determining the inputs for the sizing calculation, as described below.

The WebSphere MQ SupportPacs Performance Reports may be of assistance:

• MP16 Capacity Planning and Tuning, section "Shared Queue Setup Considerations"
• MP1B Interpreting Accounting and Statistics Data, Appendix B "Detail Layout of MQSeries Accounting and Statistics Records"

Average arrival rate of MQ messages with average size < 63KB (messages / minute)

Average size of those messages

Average arrival rate of MQ messages with average size >= 63KB (messages / minute)

1. For each queue mapped to the structure, calculate the average message size from SMF Type 116 Subtype 1 records by dividing (the total number of bytes put successfully) by (the number of MQPUTs writing data).
2. Over all queues with an average message size less than 63KB:
   1. Sum the total number of bytes put successfully.
   2. Sum the total number of MQPUTs writing data.
3. Determine the average arrival rate of MQ messages with average size < 63KB by dividing the result from step 2b by the duration of the measurement interval.
4. Determine the average size of those messages by dividing the results from step 2a by the results from step 2b.
5. Over all queues with an average message greater than or equal to 63KB, sum the total number of MQPUTs writing data.
6. Determine the average arrival rate of MQ messages with average size >= 63KB by dividing the result from step 5 by the duration of the measurement interval.

Entry Ratio

Element Ratio

These two inputs compose the entry-to-element ratio to be used in calculating the size of the structure. The entry-to-element ratio represents the average number of data elements for each list entry in the structure. The Entry Ratio represents the numerator of the ratio, and the Element Ratio is the denominator. For example, an Entry Ratio of 1 and an Element Ratio of 6 indicates an entry-to-element ratio of 1:6.

IBM recommends that you do not modify the default values for these inputs unless you have reason to believe that your workload will cause your structure to operate with a ratio other than the default. For an allocated structure, you can determine the current entry-to-element ratio by issuing the

D XCF,STRUCTURE,STRNAME=strname

command.

CF real storage message capacity (minutes)

The length of time for which the structure should be able to store incoming messages assuming that they are not processed and deleted, without overflowing into storage-class memory (SCM). This determines how much CF real storage should be allocated for the structure.

Overflow (SCM) message capacity (minutes)

The length of time for which the structure's storage-class memory (SCM) should be able to store incoming messages assuming that they are not processed and deleted. This determines how much SCM should be allocated for the structure.

Note that use of any amount of SCM at all requires a significant increase in the minimum structure size. At CFLEVEL 19, the smallest structure size that will support SCM is approximately 280M. When you specify a non-0 value for overflow capacity, CFSizer will recommend sizes that meet this requirement. If you specify a smaller value in your CFRM policy, the system may succeed in allocating the structure, but the structure will not be capable of exploiting SCM.

SCM is supported at CFLEVELs 19-25 inclusive. It has been deprecated in z17 (CFLEVEL 26) and later CFs. For structures that will be allocated in CFs at CFLEVELs outside the range that supports SCM, enter 0 for overflow capacity and see WebSphere product documentation for other available overflow mechanisms. Note that CFSIZER will continue to calculate structure sizes that account for SCM requirements if a non-0 value is entered even if the output CFLEVEL is 26 or higher, and those sizes will be valid for structures allocated in CFs that support SCM. However, if you use those calculated sizes for a structure allocated in a z17 CF, even one with SCM physically configured, the structure will not be able to use SCM and its real storage capacity will be unnecessarily constrained.