5.3 Operational considerations
|
| < Day Day Up > |
|
5.3 Operational considerations
Following are some operational considerations for the CICS environment:
5.3.1 RACF authorizations
For the CICS user, authorizations to access System Logger resources fall into two categories: definition and use of System Logger resources.
| Attention: | Refer to "Required access levels" on page 21 for authorization considerations of System Logger address space. |
When IXCMIAPU is used to predefine the CICS log streams (including the MVS log stream models) the user requires the following authorizations:
-
ALTER access to RESOURCE(MVSADMIN.LOGR) CLASS(FACILITY)
-
ALTER access to this profile is required to delete and define log structures in the System Logger policy. For users who only want to read the definitions, READ access is sufficient. For example:
PERMIT MVSADMIN.LOGR CLASS(FACILITY) ACCESS(ALTER) ID(your_userid)
-
UPDATE access to RESOURCE(MVSADMIN.XCF.CFRM) CLASS(FACLITY)
-
UPDATE access to this profile is required to define structures in the CFRM policy. For example:
PERMIT MVSADMIN.XCF.CFRM CLASS(FACILITY) ACCESS(ALTER) ID(your_userid)
-
ALTER access to RESOURCE(log_stream_name) CLASS(LOGSTRM)
-
ALTER access to this profile is required to define, update, and delete both DASD-only and Coupling Facility log streams.
-
For example:
RDEFINE LOGSTRM log_stream_profile UACC(NONE) [NOTIFY] PERMIT log_stream_profile CLASS(LOGSTRM) ACCESS(ALTER) ID(your_userid)
-
UPDATE access to RESOURCE(IXLSTR.structure_name) CLASS(FACILITY)
-
UPDATE access to this profile is required to specify a structure name on the log stream definition.
RDEFINE FACILITY IXLSTR.structure_name_a UACC(NONE) [NOTIFY] PERMIT IXLSTR.structure_name_a CLASS(FACILITY) ACCESS(UPDATE) ID(your_userid)
-
ALTER access to RESOURCE(IXLSTR.structure_name) CLASS(FACILITY)
-
ALTER access to this profile is required to define and delete CF structures in the System Logger policy.
-
For example:
RDEFINE FACILITY IXLSTR.structure_name_a UACC(NONE) [NOTIFY] PERMIT IXLSTR.structure_name_a CLASS(FACILITY) ACCESS(ALTER) ID(your_userid)
For CICS regions which dynamically create (autoinstall) log streams using the IXGINVNT service, the CICS region userid must have the following authorization:
-
ALTER access to RESOURCE(log_stream_name) CLASS(LOGSTRM)
-
ALTER access to this profile is required in order for CICS to be able to define new log streams in the System Logger policy. A profile is required for each log stream. It may be more efficient to use a generic profile by region such as region_userid.applid.* where region_userid.applid are the first two qualifiers of the log stream names.
-
UPDATE access to RESOURCE(IXLSTR.structure_name) CLASS(FACILITY)
-
UPDATE access to this profile is required to allow CICS to specify a structure name when it dynamically creates a log stream.
-
For example, consider the log streams are to be named region_userid.applid.DFHLOG and region_userid.applid.DFHSHUNT, the following permissions would allow the CICS region to define DFHLOG and DFHSHUNT as Coupling Facility log streams. The access is defined as follows:
PERMIT region_userid.applid.* CLASS(LOGSTRM) ACCESS(ALTER) ID(region_userid) PERMIT IXLSTR.structurename CLASS(FACILITY) ACCESS(UPDATE) ID(region_userid)
-
If the log streams to be used by the CICS region have been pre-defined to the System Logger, CICS is only required to have UPDATE authority to the log stream profiles in order to be able to use them. For example:
PERMIT region_userid.applid* CLASS(LOGSTRM) ACCESS(UPDATE) ID(region_userid)
Refer to the following documentation for additional information:
-
The section entitled "Define Authorization to System Logger resources" in z/OS MVS Setting Up a Sysplex, SA22-7625.
-
The section entitled "Authorizing access to MVS log streams" in the CICS Transaction Server for z/OS Installation Guide, GC34-5985.
-
The section entitled "Security for Journals and log streams" in the CICS Transaction Server for z/OS RACF Security Guide, SC34-6011.
5.3.2 Data set lifetime
From an operational point of view it's important to understand the life and naming conventions of the various log stream data sets associated with the CICS log streams.
Staging Data Sets
The High Level Qualifier (HLQ) is specified on the log stream definition. System Logger Staging data sets used with a DASD-only log stream are of the form:
HLQ.LSN.sysplex_name
The sysplex_name is specified as SYSPLEX() in the COUPLExx member in SYS1.PARMLIB. The sysplex name is used to make the data set name unique within the sysplex, ensuring only one system at a time can use the log stream. For example:
PRODSYSA.IYOT1.DFHLOG.PLEXB - PRODSYSA is the High level Qualifier - IYOT1.DFHLOG is the log stream name - PLEXB is the sysplex name
Staging data sets used with a Coupling Facility log stream are of the form:
HLQ.LSN.system_name
The system_name is specified in the IEASYSxx, IEASYMxx, or Loadxx members of SYS1.PARMLIB. The system name identifies the z/OS image within the sysplex.
PRODSYSA.IYOT1.DFHLOG.MV55 - PRODSYSA is the High Level Qualifier - IYOT1.DFHLOG is the log stream name - MV55 is the z/OS image name
Staging data sets are allocated when the first exploiter connects to the log stream, and exist only for the period of time it is connected to the log stream. When the last connector disconnects, the data is offloaded and the staging data set deleted.
Offload data sets
Offload data sets, sometimes referred to as log data sets, are named as follows:
HLQ.LSN.sequence# PRODSYSA.IYOT1.DFHLOG.A0000003 - PRODSYSA is the High Level Qualifier - IYOT1.DFHLOG is the log stream name - A0000003 is the sequence number of the offload data set assigned by the System Logger
The sequence number begins with A0000000 when the first offload data set is allocated (this happens as soon as you add the log stream definition to the System Logger policy). The number will be incremented each time a new offload data set is allocated to the log stream. If/when the log stream is deleted and redefined, the number will be reset to A0000000.
CICS knows nothing about the offload data sets and an INITIAL start of CICS does not alter/reset the sequence number.
Figure 5-14 on page 161 is an example showing an ISPF display of the offload data sets for IYOT1.DFHLOG. Note this is a DASD-only log stream (the staging data set lowest qualifier is the sysplex name) and CICS is currently connected (staging data sets only exist for the duration of time CICS is connected to the log stream).
 |
DSLIST - Data Sets Matching GRAUEL.IYOT1.DFHLOG Command - Enter "/" to select action Message Volume ------------------------------------------------------------------------------- OFFLOAD data set GRAUEL.IYOT1.DFHLOG.A0000003 *VSAM* GRAUEL.IYOT1.DFHLOG.A0000003.DATA PBDA02 STAGING data set GRAUEL.IYOT1.DFHLOG.PLEXB *VSAM* GRAUEL.IYOT1.DFHLOG.PLEXB.DATA PBDA06 LSN = LogStream Name (IYOT1.DFHLOG) HLQ = High level qualifier - specified on logstream definition (GRAUEL) A0000003 is the offload data set sequence number PLEXB is the sysplex name indicating this is a staging data set for a DASDONLY logstream
|
Figure 5-14: Staging and offload data sets for IYOT1.DFHLOG log stream
The RETPD parameter on the log stream definition, allows you to specify a retention period for log stream data. With RETPD, you specify the number of days the data in the log stream is to be kept, even if the data has been marked for deletion using an IXGDELET call.
For example, if you specify RETPD(7) in the System Logger policy for a log stream, the retention period for data in that log stream is 7 days from the time the data is written to the log stream. System Logger processes the retention period on a offload data set basis. Once the retention period for all the data in the offload data set has expired, the data set is eligible for deletion. The data might not be physically deleted as soon as it hits the retention period. The point at which the data is physically deleted depends on when the data set fills and the specification of the AUTODELETE parameter. To understand when the data sets will be physically deleted, refer to 2.7.2, "When is my log data or offload data set physically deleted?" on page 64.
| Note | The System Logger retention period applies to the age of the log data, not the data set. |
AUTODELETE(NO) means the log data can be physically deleted only after the data has been marked for deletion via an IXGDELET call and after any retention period specified for the log stream has expired. AUTODELETE(NO) is the default.
AUTODELETE(YES) means log data can be physically deleted either when the data is marked for deletion (by IXGDELET) or when a retention period specified for the log stream data expires. AUTODELETE(YES) is designed to speed physical deletion of log data.
Specifying anything other than AUTODELETE(NO) and RETPD(0) for DFHLOG and DFHSUNT can have a disastrous effect on CICS, affecting both performance and availability. With RETPD>0, even though CICS attempts log tail management, all data will be offloaded to the offload data sets and held for the number of days specified for RETPD. AUTODELETE(YES) lets System Logger (rather than CICS) decide when to delete the data. When a new offload data set is allocated and AUTODELETE(YES) is specified without a retention period, System Logger will delete the data on the old offload data set. If CICS needs the data for backout, the result will be an 804 return code from System Logger and CICS will terminate with a DFHLG0772.
As for the forward recovery or user journal log stream, it is usually suggested to use AUTODELETE(NO) and to specify a value as RETPD. Specifying a value as RETPD ensures the records are going to be kept for this period. AUTODELETE(NO) should be used because both forward recovery and user journal records are processed by utilities and afterwards deleted by the utilities themselves.
Figure 5-15 contains a summary of when the offload data sets are deleted, based on the AUTODELETE and RETPD specifications.
| AUTODELETE(NO) RETPD(0) | Log data sets are eligible for deletion when all data has been deleted via an IXGDELET call. This combination must always be used for DFHLOG and DFHSHUNT. |
| AUTODELETE(NO) RETPD(xx) | All data is offloaded from interim storage to the offload data sets. Offload data sets are eligible for deletion when all data has been deleted via an IXGDELET call and the retention period has expired. This combination should not be used for DFHLOG and DFHSHUNT. |
| AUTODELETE(YES) RETPD(xx) | All data is offloaded from interim storage. Offload data sets are eligible for deletion when either all the data has been deleted or the retention period has expired. This combination should not be used for DFHLOG or DFHSHUNT. |
| AUTODELETE(YES) RETPD(0) | Offload data sets are deleted when the next offload data set is allocated. This combination should not be used for DFHLOG and DFHSHUNT as it is possible for recovery data to be deleted, making backout impossible. |
Figure 5-15: Offload data set deletion
5.3.3 HSM considerations
Many installations use DFSMShsm to manage the offload data sets. However, caution should be used when allowing DFSMShsm to manage any System Logger data sets. Staging data sets and the offload data sets for DFHLOG and DFHSHUNT should not be under the control of DFSMShsm.
If SETSYS INTERVALMIGRATION has been specified in the ARCCMDxx member, DFSMShsm will, on a regular interval (default is 60 minutes), examine the managed volumes to see if the allocated space is over the specified high threshold. If the high threshold has been reached, it will begin the migration of data sets to reach the low threshold value.
When DFSMShsm is about to migrate (or restore) a data set, it holds the serialization lock (ENQ) for the file. If System Logger attempts to allocate or connect to the file at this time, Media Manager (a component of DFSMS) will return an error. The error as presented does not indicate a temporary condition, so it's treated as though the file is inaccessible and a gap-type error or an offload failure is returned to CICS depending on which operation is in progress.
Examples would be return code 8, reason code 84A, or return code 4 with reason code 403.
CICS treats this as a log integrity error and terminates with message DFHLG0772.
This is another manifestation of the SHAREOPTIONS problems as defined earlier in "LS_SIZE" on page 150 for Coupling Facility log streams or "LS_SIZE" on page 155 for DASD-only log streams.
5.3.4 Disaster recovery
Disaster recovery brings in a new set of considerations for the CICS environment. Log streams can not be simply transported using a volume dump of the volume containing the staging or offload data sets.
There are options to enable disaster recovery of CICS systems using log streams. The first is to simply carry the CICS libraries to the remote site, define (or delete and redefine) the log streams and issue an INITIAL start of CICS. However any transactions in-flight at the point of failure would not be backed out, leaving an exposure for data issues.
The other option is to use a disaster recovery product such as Geographically Dispersed Parallel Sysplex with Peer to Peer Remote Copy (GDPS/PPRC) or Extended Remote Copy (GDPS/XRC) to propagate the DASD data to the remote site. Using either of these products allows the mirroring of staging data sets, the LOGR CDS, the z/OS catalogs, all CICS data sets, and all the System Logger data sets to provide a consistent state at the disaster recovery site. Only when the secondary site has the data in a consistent state can an emergency restart of the CICS regions be performed.
It is important to note Coupling Facility log stream must be duplexed to staging data sets in order for this process to work.
Peer to Peer Remote Copy - PPRC
PPRC is a synchronous data mirroring technology; data is committed to both primary and secondary subsystems before the write is confirmed to be complete. As a consequence, this technology is sensitive to performance impact as the distance between primary and secondary subsystems increases. The maximum distance in a GDPS® environment is around 40 km. This limit is imposed by the Sysplex timer configuration - if you are only performing remote mirroring without GDPS, the distance between primary and secondary disk subsystems could be up to 103 km (IBM Enterprise Storage System).
With a synchronous mirroring technology, secondary data consistency does not come automatically, it needs to be managed. This is one of the main reasons for the existence of GDPS. GDPS/PPRC is a Continuous Availability solution, making major improvements to application availability by automating error detection and error response.
Extended Remote Copy - XRC
Due to risks, mostly related to environmental hazards such as earthquakes, blizzards, hurricanes, or flooding, some enterprises need disaster protection with a failover site outside their primary site region. In this case, ESCON® or even FICON™ technology might no longer be feasible and telecommunication facilities must be used so the two IT facilities can be connected over large distances.
Propagation delays resulting from long distances mean in many cases synchronous data mirroring would have a large performance impact. This is one of the main reasons for the existence of eXtended Remote Copy (XRC), a software-based data mirroring solution which operates asynchronously.
It is important to remember since the copy technology is asynchronous, some data loss is to be expected in a failover. On the other hand, the design of XRC ensures the data at the remote site is time consistent, whereas this is not guaranteed with PPRC.
5.3.5 Log stream sizing
Log stream data exists in temporary or interim storage, and in permanent or hardened storage. This section discusses sizing of the interim storage in order to achieve the best log stream and overall system performance. The discussion will include:
-
Sizing log streams when migrating from CICS 4.1
-
Using the DFHLSCU utility
-
Sizing DASD-only log streams
-
Sizing CF-Structure log streams
For information about sizing the permanent storage, refer to the discussion about "LS_SIZE" on page 150 for CF-Structure log streams and "LS_SIZE" on page 155 for DASD-only.
There are many variables which must be taken into account when sizing a log stream, making it difficult to get it perfect the first time. Once an initial size is determined, the log stream performance must be monitored using the SMF Type 88 records produced by the System Logger, and adjustments made as required.
Understanding the volume of data and the rate at which it is written is critical when sizing the log stream interim storage.
At this point, a review of the basic System Logger concepts found in Chapter 1, "Introduction to System Logger" on page 1 is in order.
Interim storage and duplexing
For a complete description of the interim storage and the different way of duplexing data, refer to "Log streams" on page 22. Following are the considerations which affect the CICS logging environment.
To optimize use of the dataspace, and reduce the potential impact on z/OS storage, residency time of the data should be kept to a minimum. For the CICS system log (DFHLOG and DFHSHUNT), the data should be retained in interim storage until the associated UOW commits or backs out. For non-system logs, all data is offloaded to the offload data sets so the interim storage (CF structure or staging data set) should be sized to provide minimal residency time.
Offload data sets contain data which has been offloaded from interim storage. Data is offloaded from interim storage as part of the offload process, usually initiated when the HIGHOFFLOAD threshold is reached. Offload data sets may be subsequently archived using a product like DFSMShsm.
Sizing interim storage
| Important: | Remember, sizing a logstream is an iterative process. Unfortunately, it's difficult to get it perfect the first time. Once a starting size has been identified, the SMF Type 88 records should be used to tune the log stream based on the activity during the key processing intervals. |
When calculating the size of interim storage for a log stream, the following log stream characteristics are important:
-
The number of IXGWRITE requests issued during a specified time interval.
-
CICS requests the System Logger to record information in a log stream using an IXGWRITE call. Each buffer passed may contain multiple CICS log records.
-
The number of IXGWRITE requests is found in the CICS log stream statistics (LGSWRITES), and in the SMF Type 88 records for the log stream (SMF88LWB or IXGWRITES).
-
-
Number of bytes written in the interval.
-
The number of bytes written is found in the CICS log stream statistics (LGSBYTES) and in the SMF Type 88 records (SMF88SWB) written for the log stream.
-
-
Number of bytes written per IXGWRITE, or average buffer size.
-
Bytes written divided by the number of write requests (LGSBYTES/LGSWRITES).
-
Reported as the average buffere size in the SMF 88 reports produced with IXGRPT1.
-
-
HIGHOFFLOAD percentage. This determines at which point the offload will start and also determines how much space is left between when the offload starts and when the log stream fills.
-
The number of log stream deletes for DFHLOG and DFHSHUNT.
-
This is a reflection of the number of times CICS performed log tail management. Log tail management is the process where CICS will issue an IXGDELET call to indicate records which are no longer required for recovery and may be deleted. Log tail management reduces the size required for interim storage without having to offload the data.
-
The number of log stream deletes is found in the CICS log stream statistics (LGSDELETES) and the SMF 88 data (SMF88SII and SMF88SAI).
-
-
Number of offloads during the interval.
-
Provided in the SMF Type 88 records (SMF88EO).
-
Each CICS system log stream will require enough storage to hold the data written in an Activity KeyPoint (AKP) interval + the duration of the longest UOW. Structures should be large enough to hold the sum of the data written for all connected log streams in the interval.
When migrating to CICS Transaction Server from an older release of CICS, the Log Stream sizing migration utility (DFHLSCU) should be run against the system journal (DFHJ01) and each user journal from the older release. DFHLSCU is discussed further in "DFHLSCU - Log Stream Sizing utility" on page 175.
If pre-CICS Transaction Server journals are available, skip to "DFHLSCU - Log Stream Sizing utility" on page 175.
Coupling Facility Control Code considerations
With each release of the Coupling Facility Control Code (CFCC), the minimum structure size has increased. In CF Level 12, the minimum size is now 4608K. If a structure smaller than this size is being used for CICS system log streams (DFHLOG and/or DFHSHUNT), CICS may fail to initialize following an upgrade to CF Level 12.
Example 5-1 shows the error messages received when DFHLOG was allocated to a 2 MB structure, when attempting to initialize CICS at CF Level 12.
Example 5-1: Example of inability to connect to a small structure
|
16.51.33 JOB12509 +DFHLG0103I IYOT1 System log (DFHLOG) initialization has started. 16.51.34 JOB12509 +DFHLG0786 IYOT1 173 The MVS logger has returned an error during operation IXGCONN CONNECT for log stream IYOT1.CICS22.DFHLOG. The MVS logger failed to find a suitable coupling facility for the log stream structure. MVS logger codes: X'00000008' X'00000853'. +DFHLG0103I IYOT1 System log (DFHLOG) initialization has started. IEF196I IXG206I CONNECT FAILED FOR LOGSTREAM IYOT1.CICS22.DFHLOG IEF196I IN STRUCTURE LOG_JG_2M. NO SUITABLE COUPLING FACILITY FOUND. IXG206I CONNECT FAILED FOR LOGSTREAM IYOT1.CICS22.DFHLOG 163 IN STRUCTURE LOG_JG_2M. NO SUITABLE COUPLING FACILITY FOUND. IEF196I IXG207I CF NAME: CF1 REASON CODE: 00000007 CF MINIMUM SIZE: IEF196I 4608K BYTES. IXG207ICFNAME: CF1 REASONCODE: 00000007 CFMINIMUMSIZE: 4608K BYTES. IEF196I IXG207I CF NAME: CF2 REASON CODE: 00000007 CF MINIMUM SIZE: IEF196I 4608K BYTES. IXG207I CF NAME: CF2 REASON CODE: 00000007 CF MINIMUM SIZE: 4608K BYTES. IXL013I IXLCONN REQUEST FOR STRUCTURE LOG_JG_2M FAILED. 161 JOBNAME: IXGLOGR ASID: 0013 CONNECTOR NAME: IXGLOGR_SYSD IXLCONN RETURN CODE: 0000000C, REASON CODE: 02010C08 CONADIAG0: 00000002 CONADIAG1: 00000008 CONADIAG2: 00000C08 +DFHLG0786 IYOT1 173 The MVS logger has returned an error during operation IXGCONN CONNECT or log stream IYOT1.CICS22.DFHLOG. The MVS logger failed to find a suitable coupling facility for the log stream structure. MVS logger codes: X'00000008' X'00000853'. +DFHLG0731 IYOT1 A failure has occurred while opening the system log (DFHLOG). CICS will be terminated.
|
When DFHLSCU is not used for sizing
If there are no pre-CICS Transaction Server journals available, the use of DFHLSCU is not appropriate. In those cases, the methodology used to size the DFHLOG and DFHSHUNT log streams would follow the process listed in the following example. Using this method may result in oversizing the log stream which should then be reduced based on the activity reported in the SMF Type 88 records.
The non-system logs (user journals, forward recovery logs, and auto journals) are considered to be funnel-type log streams (all data is offloaded). The size of the interim storage should be much smaller than the space allocated to the log data set in CICS V4.1. Oversizing non-system logs increases the working set of the System Logger and may result in overall system paging problems.
DFHLOG and DFHSHUNT example
Consider a hypothetical transaction which causes 42 log records to be written each time it is executed.
To be able to arrive at a ballpark value for the amount of interim storage required for the log stream, collect data relating to the number of transactions, transaction duration, and the journal activity in the CICS V4.1 region. The CICS statistics interval should be set to match the SMF interval. In the sample case, the SMF interval and CICS statistics interval were set to five minutes for a CICS V4.1 region. The CICS statistics interval is set using the CEMT command while the SMF interval is set in SYS1.PARMLIB.
When using the z/OS Workload Manager (WLM) in goal mode, it is possible to define a report class for CICS transactions. The report class is used to show the number of transactions ended in the SMF interval, the transaction rate (number of transactions ending per second), and the response time.
The same information can be gathered using a Report Performance Group, if WLM is being used in compatibility mode. For guidance with defining a compatibility mode Report Performance Group, refer to the section entitled "Defining Service Classes and Performance Goals" in z/SO MVS Planning: Workload Management, SA22-7602.
Figure 5-16 is an example of the information provided when a report class is used. In this case all JOR* transactions have been grouped into a report class called RJORIY1 to identify the transactions as having run in the IYOT1 region.
|
REPORT BY: POLICY=WLMPOL REPORT CLASS=RJORIY1 DESCRIPTION =Report class -JOR trans IYOT1 TRANSACTIONS TRANS.-TIME HHH.MM.SS.TTT AVG 0.00 ACTUAL 163 MPL 0.00 EXECUTION 0 ENDED 16479 QUEUED 0 END/S 54.93 R/S AFFINITY 0 #SWAPS 0 INELIGIBLE 0 EXCTD 0 CONVERSION 0 AVG ENC 0.00 STD DEV 0 REM ENC 0.00 MS ENC 0.00
|
Figure 5-16: RMF Report Class for the JOR* Transactions in a R410 region
The information presented is for an SMF interval, which has been set to five minutes. The number of transactions which ended in the interval was 16479, the transaction rate was 54.93 per second, and the average transaction duration (response time) was163 seconds.
Figure 5-17 provides the interval statistics for journals in a CICS V4.1 region during the same five minute window used in Figure 5-16. The activity for Journal 1 indicates 1039743 records were appended to the buffer, with 196349 blocks written. The average blocksize size was 560 bytes.
|
JOURNALS ________ Journal Journal Records Blocks Buffer Ave. O/P Last Vol Tapes Tapes Waits on Archives Datasets ID Type Written Written Full Blk size Written Opened Left Archive Submit. Opened _______________________________________________________________________________________________________ 1 DISK2 1039743 196349 0 560 0 0 0 0 0 3 DISK2 0 0 0 0 0 0 0 0 0 ________________________________________________________________________________________________________ *TOTALS* 1039743 196349 0 0 0 0 0 0
|
Figure 5-17: Sample Journals statistics for a CICS V4.1 region
Dividing the number of records by the number of transactions (1039743/16479) gives an average of 63 buffer adds per transaction. To be totally accurate, there were 199 CSKP tasks which executed in the interval, but the average would still round to 63.
It's important to understand the number and size of the records in CICS Transaction Server are different than those written in CICS V4.1. So, although these numbers provide some insight, the result will normally not be as accurate as using the DFHLSCU utility.
INITSIZE = 4068K + (LOGSNUM * A * B / 1024) where A = 2000 + (no. entries + 5) and B = (AVGBUFSIZE * 1.1289) + 195
| Note | The original formula used a value of 310 for fixed costs. As function has been added to the CFCC code, the value has increased. Testing with CF Level 12 has shown the minimum System Logger structure size is 4068K. For the purposes of this book, the fixed costs value is being changed to 4068K. Subsequent tests show the resulting structure is slightly larger than required, so the log stream activity should be monitored and the size adjusted to meet the log stream requirements. |
Using the formula for INITSIZE, we can estimate the size required using the CICS V4.1 information, based on the following information:
| Transaction rate | 54.93 per second. |
| Transaction duration | .163 seconds. |
| 63 journal buffer appends per transaction. | |
| 654.5 (196349 writes /300 seconds in the interval) journal writes (IXGWRITEs) per sec. | |
| Average buffer size is 560 bytes. | |
| AKPFREQ is set to 4000. | |
When a resource manager calls the CICS logger domain and the record is added to the CICS log buffer -- it is considered a buffer append. AKPFREQ defines the number of buffer appends before an activity keypoint is initiated.
akpintvl = AKPFREQ /((number of transaction in interval * buffer appends per trans) = (4000 buffer appends) / (54.93 tran/sec * 63 buffer appends/trans) = 4000/3460.6 = 1.16 seconds or 51.8 times per minute no. entries = ((1.16 + 0.163 sec) * (654.5 writes/sec))/0.9 = ((1.323)*(980)/0.9 = ((865.90))/0.9 = 962.1 round to 963 B = (AVGBUFSIZE * 1.1289) + 195 = (560 * 1.1289)+ 195 = (632.18) + 195 = 827.18 A= 2000 + (no. entries +5) = 2000 + (963 +5) = 2968 In this sample there will be one log stream in the structure INITSIZE = 4068K +((logsnum * A * B)/1024) = 4068K +((1 * 2968 * 827.18)/1024) = 4068K + (2455070.24)/1024 = 4068K + 2397.52K = 6465.52K
Remember, the size required is workload dependent. Any deviations in the workload might alter the amount of interim storage required.
There seems to be a additional variable with CF Level 12 based on the maximum structure size (SIZE) specified in the structure definition. Testing using a 5 MB structure, based on the above calculations, with log defer (LGDFINT) set to 5 milliseconds and 0, did not produce the transaction throughput expected.
To eliminate contention on the logstream the structure was expanded to 10M. The results are presented as samples A and B in Example 5-2.
Example 5-2: Sample IXGRPT1 report along with data reported from RMF and DFH0STAT
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ___________________________________________________________________________________________________________________ (A) AKPFREQ 1000 LGDFINT 5 10M structure HIGHOFFLOAD 80 LOWOFFLOAD 50 12/12/02 0:45:00 AM (SMF INTERVAL TIMESTAMP 'B8A9F9222BB00000'X) IYOT1.CICS22.DFHLOG LOG_JG2_10M 4560403 5881856 0 7417 7371 46 0 614 4418914 7190 0 0 6 0 0 0 0 0 0 ********************************************************************************************************************** (B) AKPFREQ 1000 LGDFINT 00 10M structure HIGHOFFLOAD 80 LOWOFFLOAD 50 12/12/02 0:55:00 AM (SMF INTERVAL TIMESTAMP 'B8A9FB5E60100000'X) IYOT1.CICS22.DFHLOG LOG_JG2_10M 320447741 531816704 0 1039948 1025325 14622 0 308 320157518 1039384 0 0 592 0 0 0 0 0 0
|
DASD-only
The following formula calculates the value to be specified on the STG_SIZE parameter of the log stream definition; that is, the size is expressed as a number of 4K blocks:
Staging DS size [No. of 4K blocks] = (AKP duration) * No. of log writes per second for system log where: AKP duration = (CICS TS 390 AKPFREQ) / (No. of buffer puts per second)
The values for the number of log writes per second and buffer puts per second can be taken from your CICS/ESA 4.1 statistics.
Sizing non-system log streams
There are slight differences between a User journal, a forward recovery log, and an auto journal. Data on a User journal is written directly by an application, for example when the application issues an EXEC CICS WRITE JOURNALNAME command. A forward recovery log contains "after" images used to recover the file updates which are then applied to an image copy of a VSAM file. Forward recovery logs are used by products such as CICS/VR. An auto journal may contain a combination of records based on the file definition parms JNLADD, JNLREAD, JNLSYNCREAD, JNLSYNCWRITE, JNLUPDATE, and JOURNAL.
The are also subtle differences in the amount of data written to the log/journal. In all cases, each block written will contain a x'28' (decimal 40) byte header. For User journals, CICS appends 68 bytes of information to each record written. For forward recovery and auto journal log streams, 84 bytes of CICS information plus the length of the record key is appended to each log record. Refer to CICS TS for z/OS Customization Guide, SC34-5989 for information regarding the record format.
Another difference is the point in time the data is actually written to the log stream. For a User and auto journal, the write happens when the buffer fills. For a forward recovery log, the data is written at syncpoint.
In the following descriptions, the goal is to define the log stream so residency time is about one minute. To reduce the overall impact to the z/OS image, the residency time should be kept short, therefore reducing the working set for the System Logger.
Several pieces of information are required:
-
MAXBUFSIZE for the log stream.
-
Average log record size and key length.
-
Number of records written in a given interval.
-
The CICS log stream type (USER, auto journal, forward recovery).
-
Physical log stream type (Coupling Facility log stream or DASD-only).
For a DASD-only log stream, data is written in 4K (4096 bytes) control intervals (CI). This means the size of the actual data placed into interim storage is rounded to a 4096 byte boundary. Divide MAXBUFSIZE by 4096 to determine the number of CIs required to hold a full buffer. The number of CIs also represents the number of pages required in the System Logger dataspace (for both DASD-only and CF-Structure log streams). When MAXBUFSIZE is set at 65532, it will hold up to 16 CIs of data.
For CF-Structure log streams, the data placed into interim storage is rounded to the element boundary (256 or 512 bytes). For additional information refer to "IXGRPT1 observations and possible actions" on page 183.
The suggested process for log stream sizing:
-
Determine MAXBUFSIZE
-
For DASD-only, this is specified on the log stream definition (65532 is recommended to optimize the I/O).
-
For a CF-Structure log stream, it is specified on the structure definition in the System Logger policy (for CICS log streams, the recommended value is 64000).
-
CICS adds a 40 byte header to each block written - so the usable size is (MAXBUFSIZE - 40 bytes).
-
-
Determine the record size
-
For a user journal -- data record + 68 bytes of CICS description.
-
For an auto journal -- data record + keylength + 84 bytes for CICS descriptor.
-
For a forward recovery log - data record + keylength + 84 bytes for CICS descriptor.
-
-
Identify the amount of data written within an interval
-
(transaction rate per second)*(records per transaction)*(record size).
-
-
Establish the number of data CIs created per second
-
# of data CIs = the amount of data written in one second, divide by 4096, and round up.
-
-
Determine the buffer fill and spill (write to the log stream) rate
-
MAXBUF CIs = (MAXBUFSIZE- 40) divided by 4096, round up.
-
Fill rate in seconds = MAXBUF CI divided by # of data CIs.
-
# buffer fills per minute = 60 seconds divided by the fill rate.
-
-
Define the HIGHOFFLOAD value in CIs
-
HIGHOFFLOAD CIs = MAXBUF CIs times # buffer fills per minute.
-
-
The size of the staging data set (STG_SIZE) is:
-
HIGHOFFLOAD CIs times 1.18 - if HIGHOFFLOAD is set to 85%.
-
HIGHOFFLOAD CIs times 1.25 - if HIGHOFFLOAD is set to 80%.
-
User Journal
For purposes of discussion, JORC is a CICS transaction which writes to a user journal. It writes 80 byte records and there are 42 writes per task. The transaction rate is 6 transactions per second, running in sequential order.
For a DASD-only log stream, data is written in 4 KB (4096 bytes) control intervals (CI). This means the size of the actual data placed into interim storage is rounded to a 4096 byte boundary.
For DASD-only log streams, MAXBUFSIZE should be set to 65532. With a MAXBUFSIZE of 65532, subtract 40 bytes for the header, leaving 65492 bytes for data. Each record is 148 bytes (80 bytes of data plus 68 bytes of CICS information). Dividing 65492 by 148 yields a record count of 442 will fit in the buffer.
442 records * 148 bytes/record = 65416 + 40 header = 65456 bytes will be used in each buffer.
Since we know each transaction writes forty-two 148 byte records and the rate is 6 transactions a second, the data written in one second is 42*148*6= 37296 bytes. Divide 37296/4096 and rounding up indicates 10 CIs of data are written each second. The buffer holds 16 CIs of data so the buffer will fill every 1.6 seconds or 37.5 times a minute. This equates to 600 CIs/minute (16 CIs per second * 37.5 fill intervals per minute).
If you want to have an offload occurring roughly once every minute, you must size the data set so that the HIGHOFFLOAD value equates to 600 CIs. For example, if HIGHOFFLOAD is set to 85%, STG_SIZE would be set to 706 ((100/85) * 600).
The SMF Type 88 data shown in Figure 5-18 reports the results. The SMF interval has been set to five minutes, note there have been five offloads in the five minute interval. Also note the STG THLD field is also equal to five, indicating there were no IXGWRITE calls issued for this log stream while the offloads were running.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER LOGSTREAM NAME-- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD 12/02/02 5:25:00 PM (SMF INTERVAL TIMESTAMP 'B89E460005300000'X) IYOT1.IYO1.DFHJ02 *DASDONLY* 11127520 11837440 11461800 170 0 0 0 65456 0 0 12185600 179 5 0 0 0 5 0 0
|
Figure 5-18: Sample IXGRPT1 report for a DASD-only User Journal
For a CF-Structure log stream the process is the same, but you must determine how much of the structure will be occupied by the log stream. A point to remember is the data is rounded to a 256 byte boundary when the buffer is written (assuming you used the recommended MAXBUFSIZE of 64000).
With the same transaction rate and record size (42 148-byte records per transaction with a transaction rate of six transactions a second), the data written in one second is 42*148*6= 37296 bytes.
Using a CF-Structure log stream which has a MAXBUFSIZE of 64000, 432 records can be written to the buffer ((64000-40)/148).
432 records * 148 bytes/record = 63936 + 40 header = 63976 bytes will be used in each buffer. The size is then rounded to a 256 byte boundary, making it 64000.
Writing 37296 bytes per second gives a buffer fill rate of 1.7 seconds (64000/37296), or 35.3 times per minute. The amount of data written in one minute is:
35.3 buffers/minute * 64000 bytes/buffer = 2,259,200 or 2.2 MB/minute
Using a HIGHOFFLOAD value of 85%, the portion of the CF structure available to this log stream should have a size of 2.59 MB (2.2 MB * 1.18) in order to provide a residency time of one minute.
System Logger requires some space for control information, so the size should be rounded up. The structure size should be based on the sum of the calculated values for each stream, plus about 4 MB for System Logger control information (based on CF Level 12).
Auto Journal
To size a DASD-only auto journal, the process is much the same as described for a User journal. However, in the case of an auto journal CICS will add 84 bytes, plus the length of the key to each block of data. A 40 byte header is also written at the beginning of each block. The sample used in this case is the same transaction (JORC) (without the writes to the user journal). It reads from a VSAM file and rewrites the same record, with JNLUPDATE bring specified for the file. The records are 80 bytes with a 6 byte key, there are 30 log writes per task, and the transaction rate is 6 per second.
MAXBUFSIZE is set to 65532 (this is a DASD-onlylog stream). Subtract 40 bytes for the header, leaving 65492 bytes for data. Each record is 170 bytes (80 bytes of data + 6 byte key + 84 bytes of CICS information). Dividing 65492 by 170, 385 records can be written in each buffer. Therefore, 385 records * 170 bytes per record + the 40 byte header = 65490 bytes will be used in each buffer.
We know each transaction writes thirty 170-byte records and the rate is 6 transactions a second, so the data written in one second is 30*170*6 = 30600 bytes.
Divide 30600 bytes/second by 4096 bytes/CI and round up for a value of 8 CIs of data. The buffer holds 15 CIs of data (65492/4096) so the buffer will fill every 1.875 seconds or 32 times per minute.
The amount of data written in one minute is calculated as:
32 buffers/minute * 15 CIs/buffer = 480 CIs per minute
If the desired offload rate is once every minute, the staging data set must be sized so the HIGHOFFLOAD value equates to 480 CIs. For example, if HIGHOFFLOAD is set to 85%, STG_SIZE would be set to 565 ((100/85) * 480).
Using the value calculated, the SMF Type 88 data shown in Figure 5-19, reports the offloads are happening about every 50 seconds.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER LOGSTREAM NAME-- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD 12/01/02 11:15:00 PM (SMF INTERVAL TIMESTAMP 'B89D525DB8500000'X) IYOT1.IYO1.DFHJ03 *DASDONLY* 12901530 13717504 13761300 197 0 0 0 65490 0 0 14622720 214 6 0 0 0 6 0 0
|
Figure 5-19: Sample IXGRPT1 report for a DASD-only Auto Journal log stream
For a CF-Structure log stream, the process is the same, but you must determine how much of the structure will be occupied by the log stream. Another point to remember is the data is rounded to a 256 byte boundary when the buffer is written (assuming you used the recommended MAXBUFSIZE of 64000).
With the same transaction rate and record size (thirty170 byte records per transaction with a transaction rate of 6 transactions a second), the data written in one second is 30*170*6= 30600 bytes. A 40 byte header is added at the start of each buffer.
Using a CF-Structure log stream which has a MAXBUFSIZE of 64000, 376 records can be appended to each buffer ((64000-40)/170).
376 records * 170 bytes/record = 63920 + 40 header = 63960 bytes will be used in each buffer. The size is then rounded to a 256 byte boundary, making it 64000.
Writing 30600 bytes per second gives a buffer fill rate of once every 2.0 seconds (64000/30600) or 30 times per minute.
The amount of data written in one minute therefore is:
30 buffers/minute * 64000 bytes/buffer = 1,920,000 (1.92M) bytes/minute.
Using a HIGHOFFLOAD value of 85%, the portion of the CF structure available to this log stream should have a size of 2.27 MB (1.92 MB * 1.18) in order to provide a residency time of one minute.
System Logger requires some space for control information, so the size should be rounded up. The structure size should be based on the sum of the calculated values for each stream, plus about 4 MB for System Logger control information (based on CF Level 12).
Forward Recovery Logs
To size a DASD-only forward recovery log, the process is once again the same with the difference in the fact records are forced out (written to the log stream) at syncpoint. In addition, the record volumes are usually higher because a single log stream is often used for many files.
Once again, the JORC transaction is used with a transaction rate of 6 per second. Since the records are forced at syncpoint, the number of records logged in the UOW must be understood. In the sample, the transaction issues 7 read/updates followed by a rewrite in each UOW. The records logged are 80 bytes in length with a 6 byte key. There are multiple UOWs per task, which does not affect the result, since the buffer is written during syncpoint processing for each UOW.
Each record is 170 bytes (80 bytes of data + 6 byte key + 84 bytes of CICS information). The amount of data written for each UOW, is (7 records per UOW) * (170 bytes per record) + 40 (header) = 1230 bytes. So even though MAXBUFSIZE is set to 65532, the actual buffer space used is only 1230 bytes per UOW. There are 6 UOWs per task. With a transaction rate of 6 transactions per second, each writing 6 buffers (1 for each UOW), there are a total of 36 1230-byte buffer writes per second (44,280 bytes).
For DASD-only, each buffer write requires a 4 KB CI, even though there are only 1230 bytes. Therefore, 36 CIs are used each second, 2160 (36*60) are used in a minute. In this case, 2160 CIs times 1.18 (assuming HIGHOFFLOAD of 85%) = a STG_SIZE of 2549 for a residency time of one minute.
Using an STG_SIZE of 2549 CIs, the SMF Type 88 data Figure 5-20 shows 5 offloads in the 5 minute SMF interval. Note the number of staging thresholds is 55, indicating an average of 10 log writes were performed during each of the offload periods. Ten isn't anything to worry about; however, if the number begins to grow it may be an indication of problems in the offload processing, such as allocation of a new offload data set. Another option would be to increase the STG_SIZE slightly to allow more data to be written between each offload.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER LOGSTREAM NAME-- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD 12/02/02 8:25:00 PM (SMF INTERVAL TIMESTAMP 'B89E6E3BB3F00000'X) IYOT1.IYO1.DFHJ03 *DASDONLY* 11729280 39059456 12593320 9536 0 0 0 1230 0 0 37609472 9182 5 0 0 0 55 0 0
|
Figure 5-20: Sample IXGRPT1 report for a DASD-only Forward recovery log
For a CF-Structure log stream, the process is the same, but you must determine what percentage of the structure will be occupied by the log stream. Also remember the data is rounded to a 256 byte boundary when the buffer is written (assuming the recommended MAXBUFSIZE of 64000 is used).
The transaction rate and record size (six 1230-byte records per transaction with a transaction rate of six per second) remain the same.
Using a CF-Structure log stream which has a MAXBUFSIZE of 64000, the size of the data written (1230) is rounded to a 256 byte boundary, 1280 bytes.
There will be 36 buffers written in a one minute interval (6 per transaction and 6 transactions per second), so the data written is:
1280 bytes/buffer * 36 buffers/minute = 46080 bytes per minute.
Using a HIGHOFFLOAD value of 85%, the portion of the CF structure available to this log stream should have a size of 55 KB (46080 * 1.18) to provide a residency time of one minute.
System Logger requires some space for control information, so the size should be rounded up. The structure size should be based on the sum of the calculated values for each stream, plus about 4 MB for System Logger control information (based on CF Level 12).
| Attention: | A common problem is the over-sizing of general log streams (user journals, forward recovery log streams, and auto journals). Oversizing causes greater amounts of data to be retained in interim storage for a longer period of time. This leads to an increase in the working set (page frames) associated with the System Logger dataspace. In addition, the length of time required to offload the data is increased. |
DFHLSCU - Log Stream Sizing utility
This section describes the use of DFHLSCU to analyze pre-CICS Transaction Server journals to determine the specifications for CICS Transaction Server log streams. If pre-CICS Transaction Server journals are not available, refer to "When DFHLSCU is not used for sizing" on page 166.
When migrating to CICS Transaction Server from an older release of CICS, the Log Stream sizing migration utility (DFHLSCU), provided in CICS Transaction Server, should be run against the CICS V4.1 system journal (DFHJ01). It's best to use the journal from a busy day in order to size for the peak workload.
DFHLSCU divides the CICS V4.1 journal into time segments based on the INTERVAL parameter supplied as input for the job. It then analyzes the log records found in each segment to determine the busiest segment based on the logging activity. The busiest segment is then used to determine the parameters for your log stream definitions and space requirements.
DFHLSCU reads the CICS V4.1 journal and converts the record sizes to the equivalent values for CICS Transaction Server. Multiplying the number of each record type by the record sizes for CICS Transaction Server provides the amount of data which will be written in a given interval.
The IXGSIZE service of the System Logger is then called to provide a size estimate for the interim storage portion of the log stream.
A value of 0 should not be specified for the INTERVAL value. A value of 0 indicates all records on the journal are to be considered as written in the same interval, that is, no time-segmenting is to occur and the period covered by the entire data set is to be used. The result will be a recommendation for a very large interim storage for the log stream.
When using DFHLSCU to define the size for DFHLOG, the value specified for TRANSDUR should reflect the length of time between syncpoints in the applications. The default for TRANSDUR is 3 seconds; remember this is not transaction response time unless the transaction does not issue syncpoints, that is, the transaction contains only one unit of work.
The actual value for the transactions in the region being migrated should be used.
If the transactions consist of a single UOW, the response time may be used.
The control statements for DFHLSCU are:
-
AKPFREQ is the value specified in the System Initialization Table (SIT)
The current setting can be verified using the master terminal command CEMT I SYSTEM.
-
Calculated values:
-
The number of log writes per transaction
The number of log writes per transaction can be estimated using the CICS performance records, or by dividing the total journal writes by the number of transactions. For CICS V4.1:
AKPINTVL = AKPFREQ/(the number of trans per second * log writes per transaction)
Number of list entries (no. entries) = ((akpintvl + trandur) * writes per sec) / 0.9
-
-
TRANSDUR — With the assumption each transaction consists of a single UOW, this is the average response time. If the transactions consist of multiple UOWs, the length of the longest UOW should be used.
-
TRANSACTION Rate or the number of transactions processed per second. The number of transactions can be determined using DFH0STAT, the CICS shutdown statistics, or summarizing the CICS performance records for the interval. Divide by the length of the interval to determine the transactions per second.
Refer to the manual CICS TS for z/OS Operations and Utilities, SC34-5991 for further details.
| Tip | The transaction rate and response time may be obtained by defining an RMF Report Class for each group of transactions or for all transactions within a region. The report in Figure 5-21 shows the transaction rate is 34.61 trans/sec with a response time of 0.259 seconds. Report Classes can be defined for CICS V4.1 as well CICS Transaction Server.
REPORT BY: POLICY=WLMPOL REPORT CLASS=RJRRIY1 DESCRIPTION =Report class for the RJRR transactions TRANSACTIONS TRANS.-TIME HHH.MM.SS.TTT AVG 0.00 ACTUAL 259 MPL 0.00 EXECUTION 0 ENDED 10383 QUEUED 0 END/S 34.61 R/S AFFINITY 0 #SWAPS 0 INELIGIBLE 0 EXCTD 0 CONVERSION 0 AVG ENC 0.00 STD DEV 431 REM ENC 0.00 MS ENC 0.00
Figure 5-21: Sample Report Class output Refer to "Defining Service Classes and Performance Goals" in z/SO MVS Planning: Workload Management, SA22-7602. |
5.3.6 Performance
Obtaining the best performance is a matter of tuning for the optimum data residency time in interim storage. For CICS system log streams (DFHLOG and DFHSHUNT), data required for backout and recovery should be available in interim storage for the duration of the unit of work. For non-system log streams, the data residency time should be such that a steady movement of data from interim storage to the offload data sets is observed while requiring a minimal amount of storage to duplex the data within the System Logger dataspace.
The performance of CICS log streams is influenced by the sizing, type, and placement of the log streams. In addition, activity keypoint frequency (AKPFREQ), and the log defer interval (LGDFINT) can have a significant impact on log stream performance. For information on parameter specification, refer to:
-
"AKPFREQ" on page 143
-
"LGDFINT" on page 144
-
"Define the log stream in the LOGR policy" on page 148
-
"DASD-only log stream" on page 153
It's important to remember the IXGWRITE calls are issued under the CICS Quasi-Reentrant (QR) TCB, hence the CPU time is charged to the transaction.
Performance tools
Performance data is available from several sources:
-
SMF Type 88 records produced by the z/OS System Logger.
-
SMF Type 110 data produced by CICS.
Includes both statistical and performance data.
-
SMF Type 70-78 data produced by RMF (or an equivalent product).
There are several tools which aide in the analysis of log stream performance problems:
-
DFH0STAT - a CICS-supplied sample transaction (STAT) collects the CICS statistics and writes them to the CICS JES log. Refer to "DFH0STAT" on page 177 for details.
-
DFHSTUP (CICS Statistics Utility Program) - used to post-process the CICS SMF Type 110 sub type 2 statistical records. Refer to "DFHSTUP" on page 181 for details.
-
CICS Performance Analyzer (part of the CICS Tools portfolio) - used to post-process the CICS SMF 110 sub type 1 performance records and SMF Type 88 records. Refer to "CICS Performance Analyzer" on page 182 for details.
-
IXGRPT1 (sample program provided with z/OS) formats and reports the SMF Type 88 data produced by the z/OS System Logger. Refer to "SMF Type 88 records and IXGRPT1 program" on page 281 for an explanation of the report fields. Refer to "IXGRPT1 observations and possible actions" on page 183 for a description of the fields which are interesting in a CICS environment.
-
Various RMF reports (Coupling Facility Activity reports, Workload Activity reports) based on the data captured in the SMF 70 -78 records. Refer to "RMF Coupling Facility Activity Report" on page 277 for details.
-
The sample DFSORT™ jobs provided with this redbook in 8.6.5, "DFSORT jobs to format SMF 88 records" on page 287. These reports provide similar information to the IXGRPT1 program, however they allow you to summarize all the activity by log stream rather than by interval, and they are also more readable than the IXGRPT1 output.
DFH0STAT
(Use: Dynamically gather CICS statistics)
DFH0STAT is supplied as a sample COBOL program in CICS.SDFHSAMP. It contains self-documenting source code which can be compiled and run as a transaction to collect CICS statistics and write them to the JES spool. The output can be viewed under TSO. The SIT parm SPOOL=YES is required. The information presented with DFH0STAT is also available in the CICS shutdown statistics. The interval reported is based on the CICS stats interval—to be precise, it is actually the data since the last stats reset, which is determined by the stats interval.
A compiled version is available in CICS Transaction Server V2.2.
A sample output is shown in Figure 5-22. The MVS release is provided in the System Status section, along with the values for Activity Keypoint Frequency (AKPFREQ) and log stream Deferred Force Interval (LGDFINT).
Figure 5-22: Sample DFH0STAT output
In the log stream statistics we see each log stream connected to this CICS region. If the log stream resides in a CF structure, the structure name is given; if it is a DASD-only log stream, the structure name is blank. In the example, IYOT1.DFHLOG and user journal J02 are DASD-only log streams, while IYOT1.DFHSHUNT is a CF-Structure log stream in structure LOG_JG.
The values under Max Block Length are worth noting. This value is specified in the log stream or structure definition and is returned to CICS when it connects to the log stream. For a CF-Structure log stream the blocksize is specified as MAXBUFSIZE on the structure definition. The value specified in MAXBUFSIZE determines the element size for the log streams in the structure. If the MAXBUFSIZE is specified equal to or less than 65276, the element size is 256; if greater than 65276 the element size is set to 512.
For DASD-only log streams, MAXBUFSIZE may be specified on the log stream definition. MAXBUFSIZE defines the largest block which can be written to the log stream. The default value is 65532.
In either case, the MAXBUFSIZE value is returned to CICS and is used to determine the CICS log stream buffer size. Note, for user journals, unless the application uses the WAIT option, the IXGWRITE call is issued when the buffer fills. Refer to the Average Bytes column. This is the average buffer size written using IXGWRITE calls. For DFHJ02 the average size is 65,485. It is sometimes advantageous to reduce MAXBUFSIZE on a user journal to force the data into the log stream more frequently. This reduces the residency time and allows quicker access to the data from batch applications.
It's also worth noting in the case of a hard failure (MVS, CICS, or the hardware) where the data has not be written to the log stream, it will be lost. For DFHLOG and DFHSHUNT, when the region is emergency restarted, in-flight tasks would be backed-out using the information which had already been written to the log.
In the case of a user journal, the data in the buffer would be lost. There is no transaction backout associated with data lost in a non-system log buffer.
The columns entitled DASD Only, Retention Period, and Auto Delete reflect the attributes specified for the log stream in the System Logger policy.
The value given under Stream Deletes is the number of times CICS issued an IXGDELET call to the System Logger for log tail deletion.
The value under Browse Starts is a count of the number of times a browse start request is issued. Prior to CICS Transaction Server V2.2, a large value may be observed for DFHLOG in a low volume region, due to CICS using a Browse Start to verify the System Logger is still operational. In CICS Transaction Server V2.2, a change was implemented to call the System Logger function CHECK_CONNECTION_STATUS and as a result this number may not be as large as in a CICS Transaction Server V2.2 system.
The Browse Reads column reflects the number of times CICS reads the log stream to obtain information for transaction backout.
The number of Write Requests is the number of times CICS called the System Logger via an IXGWRITE. The number of Buffer Appends is a count of the times a record was added (appended) to the CICS log buffer. The number is normally larger than the number of Write Requests due to calls to the CICS logger domain which do not include the force option. For example, the records produced during activity keypoint processing are not written with the force option. In contrast, the before images for a recoverable VSAM file are written with the force option specified. Unfortunately it is not possible to predict what percentage of writes will be with the force option, it depends on the work load. If the workload is comprised of mostly updates for a recoverable VSAM file, most of the records on DFHLOG will be forced. If the bulk of the records are the result of an activity keypoint we simply append the records without force.
Buffer Full waits is a count of the number of attempts to append a record to the current log stream buffer while the buffers were logically full. This situation arises when the current log stream buffer does not have sufficient space to accommodate the journal record, and the IXGWRITE is still in progress for the alternate log stream buffer.
Force Waits is the total number of tasks suspended waiting for an IXGWRITE call to complete.
Buffer Full Waits and Force Waits can be an indication there is a delay in I/O processing. They can also be an indication the log defer interval is too large. Additional items to check are the CF service times for a Coupling Facility log stream or DASD I/O time for DASD-only log streams.
If Buffer Full and/or Force waits are seen consistently, verify the value for LGDFINT is set to 5. If the Task Journal Wait Time (JCIOWTT) is very close to the LGDFINT value, then the LGDFINT value should be decreased. Prior to CICS Transaction Server V2.2, the default value was 30. Normally the recommendation is not to reduce the value lower than 5, however, in a very high volume region it may be advantageous to set as low as 0 for CF-Structure log streams. In addition, CF service time (for CF-Structure log streams) or DASD I/O time should be investigated.
Setting LGDFINT to zero causes the data to be written to the log stream (via an IXGWRITE) immediately without waiting for additional records to be added to the buffer.
The Peak Waiter field contains the high water mark of the number of tasks (UOWs) waiting for a buffer to be written. The Current Waiter field is the number of tasks (UOWs) waiting for a buffer to be written at the point in time the statistics were collected.
Retry Errors is the number of requests to System Logger resulting in a return code indicating an error, which was subsequently retried. An example would be 868 errors returned while the staging data set is being formatted. This can happen with DASD-only log streams or if staging data sets are used with a CF-Structure log stream. For example:
01.48.56 JOB07716 +DFHLG0777 IYOT1 A temporary error condition occurred during MVS logger operation IXGWRITE for log stream IYOT1.DFHLOG. MVS logger codes: X'00000008', X'00000868'.
With CICS Transaction Server V2.2, DFH0STAT has been enhanced. The format has been changed for ease of reading and information has been added to calculate (and display) the number of log stream writes per second. The samples in Figure 5-23 and Figure 5-24 show the format of the new reports.
Figure 5-23: DFH0STAT for CICS TS 22 - part 1
Figure 5-24: DFH0STAT for CICS TS 2.2 - part 2
DFHSTUP
(Use: Evaluate the CICS statistics on a CICS statistics interval or daily basis)
The CICS statistics utility program, DFHSTUP, is an offline utility which processes CICS statistics information contained in SMF Type 110 subtype 2 records. The CICS statistics domain records interval statistics when the system initialization parameter STATRCD=ON is specified. Other statistics record types (unsolicited, requested, and end-of-day) are written regardless of the setting of the STATRCD option. For additional information on DFHSTUP refer to CICS TS for z/OS Operations and Utilities, SC34-5991.
A separate version of DFHSTUP is provided with each release of CICS, so the correct version must be used to process the data.
In the sample DFHSTUP EOD (End of Day) report shown in Figure 5-25 on page 182, you will notice the same type of information provided by DFH0STAT is presented. However, in this case it is for the entire execution of the CICS job, or for a 24 hour period if the CICS region was executing for multiple days.
Figure 5-25: Sample DFHSTUP End of Day report
In the sample report, notice the log stream IYOT3.DFHLOG has been specified with a MAXBUFSIZE of 60000, is allocated to structure LOG_JG2_20M, has a retention period of 0, and auto delete is set to NO.
The EOD report shows the overall summary for the day. To collect interval statistics, the interval may be set using the STATINT= system initialization parm, or it can be set via the CEMT master terminal transaction.
CICS Performance Analyzer
(Use: Analysis of the SMF 110 Subtype 1 CICS Performance Records)
CICS PA is a post processor for CICS SMF Type 110 subtype 1 records. It provides the ability to summarize by CICS monitoring fields, and display the API calls and resources used, along with CPU per transaction and response time.
In Release 2 of CICS Performance Analyzer, the product was enhanced to provide support for the System Logger SMF Type 88, and SMF Type 101 records produced by DB2®. The sample outputs from IXGRPT1 in Figure 5-27 and from CICS PA in Figure 5-26 show the different methods for displaying the data.
Figure 5-26: CICS Performance Analyzer Log stream Summary
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER LOGSTREAM NAME---- STRUCTURE NAME- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD _____________________________________________________________________________________________________________________ IYOT1.CICS22.DFHLOG LOG_JG2_5M 324226786 556595200 35060218 1138714 1072720 46589 19401 284 302169464 1067720 30935658 103114 378 5 5 3470 0 0 0
|
Figure 5-27: Sample IXGRPT1 Report
IXGRPT1 observations and possible actions
The following fields should be noted in the IXGRPT1 reports for CICS log streams:
-
For DFHLOG and DFHSHUNT, the number of "BYT DELETD INTERIM ST W/O DASD" should be very close to the "BYT WRITTN TO INTERIM STORAGE". A non-zero value in "BYT DELETD INTERIM ST W/DASD" indicates data is being offloaded and then deleted, costing additional processing and I/O. The BYT WRITTN to DASD should be very low.
Factors to be considered include:
-
There are long running CICS tasks, preventing log tail deletion.
-
This is not simply CICS transactions with high response times, but rather long running tasks which use recoverable resources and do not issue a syncpoint. In addition, the tasks are causing log records to be written during each activity keypoint interval.
If message DFHLG0743 (Tail of log stream log_stream_name deleted at block id X'nnnn') is not being issued for DFHLOG with each activity keypoint (message DFHRM0205), a long running task is preventing tail trimming. However, it is not unusual to see infrequent DFHLG0743 messages for DFHSHUNT. Units of work may exist on DFHSHUNT for extended periods of time. Examples are conversational tasks which have updated a recoverable resource, and mirror tasks awaiting a forget flow from the connected region.
In CICS Transaction Server, the forget flow (part of 2 phase commit) is carried with the next task attach to flow across the MRO link. This improves performance on most links, but if the usage is low, the log records for the mirror may reside on DFHSHUNT for an extended period of time. A DFHLG0743 message being issued for DFHSHUNT indicates units of work, which had been inactive, have completed. CICS APARs PQ22563 and PQ14796 reduce the amount of data recorded on DFHSHUNT. In addition, APARs PQ56315 (1.3) and PQ56341 (2.2) should be applied.
-
-
AKPFREQ is set too high
-
Use the DFHRM0205 messages to determine how often an activity keypoint is being taken.
-
-
Problems related to interim storage
-
CF-Structure log stream structure size is too small, or staging data set cannot hold as much data as the log stream structure storage.
-
Incorrect entry-to-element ratio—this can happen when log streams with very different block sizes or very different write rates are in the same structure. Dynamic changes to the entry-to-element ratio will not be made more frequently than once every 30 minutes.
-
DASD-only log streams—the size of the staging data set may be insufficient.
-
-
HIGHOFFLOAD
-
Should be set no higher than 85%.
-
-
LOWOFFLOAD
-
For DFHLOG and DFHSHUNT, set in the range of 40 - 60%.
-
For user journals, set to 0%. All data should be offloaded each time an offload is initiated.
-
-
-
Under # WRITES COMPLETED (prior to the installation of the PTF for APAR OA03055, this is only provided for CF-Structure log streams):
-
TYPE1 -- normal - this number should be high.
-
TYPE2 -- normal, but the log stream reached or exceeded the HIGHOFFLOAD value.
-
TYPE3 -- writes issued when 90% of the elements for the log stream are in use.
-
Look for HIGHOFFLOAD set to 90% or higher.
-
Tail trimming is not happening or is not being effective (see item 1 on page 183).
-
CICS is filling the space above HIGHOFFLOAD point faster than the log stream is being offloaded.
-
-
-
Under EVENTS
-
NTRY FULL indicates the number of times all log streams in the structure were offloaded due to reaching 90% of the structure entries in use.
-
This could be the result of the entry-to-element ratio being too large (AVGBUFSIZE is specified larger than necessary), or a poorly behaving application which is causing many small records to be written to a log stream which normally contains large records.
-
-
OFFLOADs are good if they are triggered by the HIGHOFFLOAD value. However, offloads are bad if they are triggered by an NTRY FULL condition. In addition, for a CF-Structure log stream, offloads should be triggered because the CF-Structure log stream reached its HIGHOFFLOAD value, not because the staging data set reached its HIGHOFFLOAD point (see STG THLD below).
-
DASD Shifts indicates the number of times a new offload data set is allocated.
-
For DFHLOG and DFHSHUNT this number should be very small. A large value here indicates too much data is being offloaded (see item 1 on page 183).
-
For user journals, each offload data set should be capable of holding multiple offloads of the log stream.
-
If the offload data set size has not been specified in the log stream definition (LS_SIZE) or in the SMS data class, the size will be determined by the value specified in the ALLOCxx member of SYS1.PARMLIB -- which defaults to 2 tracks.
-
-
STRC Full indicates the number of times a structure full condition was reached—this should always be 0.
-
STG THLD is the number of times the HIGHOFFLOAD percentage was reached for the staging data set.
-
This is good for DASD-only log streams but should not happen for CF-Structure log streams. If non-zero values are seen here for a CF-Structure log stream, the staging data set size needs to be increased so it will hold at least as much data as the log stream in the structure. A value here for a CF-Structure log stream also indicates the CF is either volatile or failure dependent or DUPLEXMODE(UNCOND) has been specified for the log stream.
-
-
Rebuild indicates the number of structure rebuilds in the interval—if this happens on a regular basis, it needs investigation.
-
Performance Analysis
Following are considerations about performance for CICS log streams.
System Log Streams
The sample discussed in "Sample workload and methodology" on page 187 shows different runs of a workload with different system set up to show how the change in these values can influence the CICS and System Logger environment with the results from the different runs. If you need additional details from a benchmark perspective of all the different and additional runs and configurations, refer to the RedPaper REDP-3768-00.
Log Stream Characteristics and Placement
In addition to tuning the CICS and system logger, there are some tuning considerations that need to be evaluated on the surrounding environment, for example the log stream placement and the DASD pooling are very important factors.
The placement and size of the log stream(s) you wish to tune must be understood. For example, are the staging and offload data sets allocated to DASD pools which provide the best performance? This not only includes the actual device access time, but activity which could make the device unavailable. For example, a reserve from another system or high activity data sets which could result in the request being queued.
Is there possible contention between log streams? For example, when there are multiple log streams in a given structure, do they have similar characteristics, that is, the volume and block size of the data written?
If the log stream in question resides in a CF, determine the largest average buffer size for log streams in the structure. This value is used to determine the entry-to-element ratio. The element size is determined by the MAXBUFSIZE value specified when the structure is defined in the System Logger policy (using IXCMIAPU). When the value is equal or less than 65276, the element size is 256. If the value specified is greater than 65276, the element size is 512.
For example, if the element size is 256 and the IXGWRITE is for 734 bytes, 3 elements are required.
The entry-to-element ratio is dynamically adjusted based on a current snapshot of the usage of all log streams connected to the structure. The snapshot will be taken about every 30 minutes and the ratio adjusted if necessary. For more information, refer to "The entry-to-element ratio" on page 26.
If there are 3 log streams in the structure, with average buffer sizes of 1800, 1450, and 734, System Logger will use the current real time average (how many records of each size) to define the entry-to-element ratio. Assuming an element size of 256 bytes, if most of the records are in the 1800-byte range the average would be 1:8. This means we expect to use 8 elements for each entry.
Consider the case where the application writes many short records, say 200 bytes, to the same log stream resulting in an average size of 734. In this situation, one entry is still used for each write, but only one of the eight assumed elements is used. The net effect is more entries are used than predicted leading to an entry full condition before HIGHOFFLOAD can be reached. Offload will be triggered, but there is no extra room to write additional records until some space is recovered. In this situation the NTRY FULL count will be equal to or greater than the number of offloads.
The important point to remember is a log stream performs best when it is contained in a structure where all log streams have similar characteristics (that is, average buffer size and amount of data written). Typically, the log streams for TORs, AORs, and FORs are different and should not be mixed. Even among AORs, two AORs may have completely different log stream characteristics. In addition, DFHLOG and DFHSHUNT should not be placed in the same structure.
Prior to z/OS 1.2, CF writes greater than 4 KB are written asynchronously which can increase response time. However, z/OS 1.2 introduced a new heuristic algorithm for deciding whether a given CF request should be sent synchronously or asynchronously. This new algorithm is discussed in Washington System Center Flash10159. The important point is that System Logger knows whether a given IXGWRITE request will be processed synchronously or asynchronously—for synchronous requests, it does not respond to the IXGWRITE requestor until the command completes, whereas for asynchronous writes, it responds with a return code indicating the write was asynchronous, and the result will be POSTed later.
CF Hardware
It's very important to understand if the log streams will be in a structure which resides in a standalone CF or in a CF which resides in the same CPC as one or more of the connected systems.
A standalone CF is considered volatile when it no longer has a battery backup—that is, in the event of a power loss, the data could not be preserved. If the CF is in the same physical CPC as the z/OS LPAR, it is considered to be failure dependent, or in the same failure domain. In either case, System Logger will (if STG_DUPLEX(YES) is specified for that log stream) duplex the data to the staging data set rather than its' dataspace. This ensures data integrity, but increases the cost and response time for log writes.
A symptom of this condition is when the CICS address space is initializing and messages are received indicating a staging data set is being formatted. Refer to "STG_SIZE" on page 152 for considerations during log stream definition.
Sample workload and methodology
The data collected includes the SMF Type 88 records, SMF Type 70 to 79 records, and the SMF Type 110 (CICS) records. The data was combined in the following charts by sample.
The workload consists of up to three CICS regions (CICS Transaction Server V2.2 and V1.3) executing under z/OS R1.4.
For the test runs, a transaction (JORM) was started via terminal input. The application reads and writes 7 records from/to a VSAM file (FILEA), issues a syncpoint, then repeats the process 6 times. It then issues an EXEC CICS Start for ten transactions (JORA-J). Each of these transactions reads and writes 7 records from/to a unique VSAM (FILEA-J), issues a syncpoint and repeats the process six times. It will then issue an EXEC CICS START for itself. This will repeat up to the number of repetitions passed from JORM (x'7500'). The 10 tasks run in parallel for 30 minutes and the region is then canceled. In cases where 3 regions are used, the process is the same in each region.
The only log streams that we are interested in these sample study are DFHLOG and DFHSHUNT. The log streams are varied between a CF-Structure log stream and DASD-only. No data is ever written to DFHSHUNT during the tests.
The data presented in each sample begins with the SMF Type 88 data followed by a combination (hand crafted to reduce the presentation space) of data from RMF and the CICS 110 records. The RMF information is taken from the workload activity reports for the CICS and System Logger address spaces. The CICS-specific information is taken from summarized CICS 110 records using the CICS Performance Analyzer.
The sample on Figure 5-28 on page 187 shows and explain the set od data collected for each run. These collection of data summarizes what is required to understand the CICS and system logger environment and should represent what kind of data you are collecting in your installation whenever you are evaluating this environment.
|
Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames DASD 0.4 8.3 0.2 .197 0.005 50.1582 50.0519 .0988 0.1 0 2.3 0.1 2571.42 1025.06 1546.36
|
Figure 5-28: Sample of the hand crafted reports
Using the example in Figure 5-28, the data on the left is for the CICS address space. The TCB, DASD I/O, and APPL% are taken from the RMF report class data.
The number of transactions per second is taken from the transaction report class.
Average CPU per task, Average response time, Average JC Wait, and Average File Wait times are taken from the CICS PA reports.
The data on the right starting with LOGR TCB is for the System Logger address space (IXGLOGR), taken from the RMF report class reports.
The meaning of each heading is:
| Type | The log stream type |
|
|
|
|
|
|
| CICS TCB | Reports the CICS TCB time in seconds for the interval, taken from the RMF report class information for the CICS address space. |
| DASD I/O | This field gives the average number of I/Os per second initiated by the region during the interval. The data is obtained from the RMF report class for the CICS region. Since the workload is based on VSAM files, this number provides a good indication of transaction throughput. |
| APPL% | Reports the percent of a CP used by the region in the report interval. |
| # Tran/Second | The number of transactions per second is found in the RMF transaction report class and in the output of DFH0STAT. |
| Average CPU/Task | The average CPU per transaction is taken from the CICS PA reports. |
| Average Resp. | The average transaction response time is provided in the CICS PA reports and the RMF transaction report class. |
| Average JC Wait | The average journal control wait time is found in the CICS PA reports and provides the average time tasks spent waiting for journal requests to complete. |
| Average File WT | This field reports the average time spent waiting for VSAM file requests to complete. |
| LOGR TCB | This field reports the TCB time consumed in the System Logger address space (IXGLOGR). The information is taken from the RMF report class for the System Logger address space. |
| LOGR SRB | This field provides the SRB CPU time used by the System Logger address space during the interval. The information is found in the RMF report class for the System Logger address space. |
| DASD I/O | This field gives the average number of I/Os per second initiated by the System Logger during the interval The data is obtained from the RMF report class for the System Logger address space. This number is a good indicator of the amount of staging and offload data set activity. |
| APPL% | Reports the percent of a CP used by the System Logger address space in the report interval |
| Storage Frames | This field reports the average storage frames allocated to the System Logger address space during the interval. A storage frame is a 4K page. The data is taken from the RMF report class for the System Logger. |
| Idle Frames | The number of pages used when System Logger is idle, that is, prior to starting the CICS region(s). |
| Net Frames | For System Logger, the increase due to CICS logging activity in the interval (represented by Net Frames) is calculated by subtracting the number of idle frames from the average storage frames. |
How Log Defer Interval (LGDFINT) can affect performance
The LGDFINT CICS SIT parameter defines the log defer interval. The interval is the length of time, specified in milliseconds, the CICS log manager is to wait before invoking the System Logger for a forced write request. The value chosen may have an impact on transaction response time. Prior to CICS Transaction Server V2.2, the default is 30 milliseconds. With CICS Transaction Server V2.2, the default has been changed to 5 milliseconds.
To understand the effects of different LGDFINT values, three different runs of the workload has been executed with different set up using a DASD-only log stream, however the results are equally applicable to CF-Structure log streams. The following are the results of the three runs to illustrate the different behaviors. The log stream was defined with a HIGHOFFLOAD of 80, LOWOFFLOAD of 50 and a STG_SIZE of 2518. AKPFREQ was set at 1000.
The first sample is shown in Figure 5-29. LGDFINT was set at 30 milliseconds.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME--- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD -------------------------------------------------------------------------------------------------------------------- (1) AKPFREQ 1000 LGDFINT 30 STG_SIZE 2518 HIGHOFFLOAD 80 LOWOFFLOAD 50 12/11/02 2:20:00 AM (SMF INTERVAL TIMESTAMP 'B8A8CC80A7400000'X) IYOT1.CICS22.DFHLOG *DASDONLY* 3032896 9834496 0 2401 0 0 0 1263 7585792 1852 0 0 1 0 0 0 1 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames DASD 1.6 37.8 0.6 1.57 .0044 11.11 11.042 0.0608 0.1 0.1 8.4 0.1 2949.35 859.09 2090.26 Logstream Writes/sec: 10.42
|
Figure 5-29: Log Defer Sample 1
At first glance, the SMF Type 88 data indicates the log stream is working fine; no data is being offloaded to the offload data set (BYT DELETD INTERIM ST W/DASD is zero). There was a single staging threshold and one offload.
The problem is not the log stream function, but rather the fact that very little work is being processed in the CICS region and the average response time is high.
From the RMF data, observe the CICS TCB time is very low (1.6 seconds), with a response time of 11.11 seconds. Also note CICS is only issuing an average of 37.8 DASD I/O per second. This DASD I/O has nothing to do with System Logger, but rather the CICS VSAM file accesses which is a direct reflection of the number of file control requests in the region. Finally notice the CICS region is only using 0.6% of an engine during this interval.
In the System Logger address space the CPU, SRB, and APPL% values are very low indicating a minimum of work is being passed to System Logger. The average number of DASD I/O is 8.4 per second, and the average net storage frames is 2090.26. The number of storage frames is an important value to watch, especially in an LPAR which is storage constrained. In this sample, the System Logger storage is 8.56M (2090.26 * 4096) due to the CICS log stream.
The average response time per transaction is 11.11 seconds with an average CPU per task of 0.0044 seconds. Note, of the 11.11 seconds response time, an average of 11.042 seconds is spent waiting for journal I/O to complete, although there are no constraints in system logger.
The delay might be because CICS is waiting for the LGDFINT interval to expire before issuing and IXGWRITE. In the next run, LGDFINT will be decreased.
In the second sample, shown in Figure 5-30, LGDFINT was reduced to 5, all other parms remained the same. This change brought the transaction throughput up from 1.57 per second in sample 1 to 4 per second in sample 2, and the average response time has dropped from 11.11 to 3.0288 seconds.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD -------------------------------------------------------------------------------------------------------------------- (2) AKPFREQ 1000 LGDFINT 5 STG_SIZE 2518 HIGHOFFLOAD 80 LOWOFFLOAD 50 12/11/02 3:05:00 AM (SMF INTERVAL TIMESTAMP 'B8A8D68F92F00000'X) IYOT1.CICS22.DFHLOG *DASDONLY* 11240854 32935936 0 8041 0 0 0 1397 30801920 7520 1368064 334 4 0 0 0 4 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames DASD 5.4 140.4 2.2 4 .0039 3.0288 2.9631 0.059 0.1 0.2 27.3 0.1 2850.76 859.08 1991.68 Logstream Writes/sec: 29.85
|
Figure 5-30: Log Defer sample 2
When evaluating CICS transaction performance issues it's important to remember there are multiple parts in transaction response time. The two major categories are execution and suspend time. Execution time is when the application, CICS management modules, exit programs, and so on, are processing as part of the transaction. In the workload used, the suspend time is comprised of waiting for VSAM file I/O and log/journal writes. Wait for redispatch is the portion of suspend time after the ECB is posted until the task is redispatched.
Reducing the value for LGDFINT from 30 to 5 means each force write will only be held for 5 ms, rather than 30 before the IXGWRITE is issued. This reduces the opportunity for additional records to be added to the buffer, but it also reduces the time a task must wait for the log write to complete.
However, this region is capable of much better throughput. As outlined earlier, the workload consists of a very small assembler application which will generate 49 log writes per task (one for each read/update and one for each syncpoint). The data indicates journal wait time is still the largest component of the response time, accounting for 2.9631 seconds of the 3.0288 second response time.
Due to the workload and the journal wait time in Figure 5-30 on page 190, the log defer interval was removed by setting it to 00. Figure 5-31 shows some interesting results.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME--- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD -------------------------------------------------------------------------------------------------------------------- (3) AKPFREQ 1000 LGDFINT 00 STG_SIZE 2518 HIGHOFFLOAD 80 LOWOFFLOAD 50 12/11/02 3:50:00 AM (SMF INTERVAL TIMESTAMP 'B8A8E09E7EA00000'X) ) IYOT1.CICS22.DFHLOG *DASDONLY* 184275302 699846656 0 170861 0 0 0 1078 701902848 171363 0 0 87 0 0 0 156 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames DASD 85.3 2277 35.2 56.83 .0038 0.1845 0.1224 0.0556 0.2 3.9 572.8 1.8 3092.09 859.08 2233.01 Logstream Writes/sec: 569.75
|
Figure 5-31: Log Defer sample 3
Setting LGDFINT to 0, means CICS will issue the IXGWRITE immediately after the log data is appened to the buffer.
Notice the number of IXGWRITES has increased from 8041 in sample 2 to 170861 in sample 3, an increase of over 21 fold. It's also interesting to note there are still multiple records per buffer (the average buffer size is 1078), indicating tasks are adding data to the buffers in the time it takes for each IXGWRITE to complete.
With the effective reduction in IXGWRITE time, there's a significant increase in transaction throughput. The transaction rate has increased from 4 transactions per second in sample 2 to 56.83 per second in sample 3, a 14 fold increase.
The average response time dropped to 0.1845, with a huge increase in the DASD I/O for both CICS and System Logger. The increase in CICS TCB time from 5.4 to 85.3 CPU seconds reflects a large increase in the amount of work being processed in the CICS region. Note that 0.1224 seconds of 0.1845 total seconds average response time per transaction are spent waiting for log writes to complete.
The increase in DASD I/O in the System Logger address space clearly reflects the fact CICS is issuing 569.75 log writes per second. From the RMF data (although not shown in Figure 5-31) the DASD requests in the System Logger address space are averaging 1.3 milliseconds.
The average System Logger storage frames for the CICS log streams has grown from 8.56M in the first sample to 9.15M in the third sample. The 0.59M increase is a small cost for the increase in throughput, increasing from 4 transactions a second in sample 2 to 56.83 transactions a second in sample 3.
| Tip | The recommendation is to start with a LGDFINT value of 5 milliseconds for all releases. A value of 00 may be valid in some cases based on the speed of the processor, for example on a z900, the overall CICS workload and the amount of data log for each transaction. The log defer interval value (LGDFINT) may be changed using CEMT I SYS. Evaluation of the results is much easier if the changes coincide with an SMF interval. |
How Activity Keypoint Frequency (AKPFREQ) can affect performance
The other CICS parameter which can affect how CICS works with System Logger is AKPFREQ (Activity Keypoint Frequency).
Although activity keypoint frequency was used in CICS/ESA V4.1, it has taken on a more significant role in CICS Transaction Server. In CICS/ESA V4.1, AKPFREQ was a measure of the physical I/O issued to the system journal (DFHJ01). In CICS Transaction Server, it is a measure of the number of appends to the log stream buffer for DFHLOG. In CICS/ESA V4.1, it was common practice to specify AKPFREQ to provide an activity keypoint every 15 minutes. In CICS Transaction Server, the value should be set to ensure an activity keypoint is taken more frequently.
It's important to remember tail trimming is initiated for DFHLOG and DFHSHUNT during the CICS activity keypoint process. The value specified for AKPFREQ defines the frequency an activity keypoint is taken, therefore the frequency of tail trimming, which has a major impact on the data residency time. Trimming the tail of the log removes records which are no longer required for backout and recovery, therefore making space available in interim storage.
With a larger AKPFREQ value, the length of time between activity keypoints increases, therefore additional data is retained in interim storage. Either data will be offloaded, costing I/O and overhead to the offload data sets, or the size of interim storage will need to be increased, leading to additional storage requirements in the System Logger dataspace.
In a very busy region, it is not uncommon to observe an activity keypoint being taken every minute.
When HIGHOFFLOAD is reached, System Logger executes the following tasks as part of the offload process:
-
Physically delete any data which has been logically deleted because of the AKPFREQ activity — and this is the goal for the DFHLOG and DFGSHUNT log stream.
-
If the previous task does not take the log stream below the LOWOFFLOAD point, data is physically offloaded to the offload data set until the LOWOFFLOAD point is reached.
-
Remove data no longer required from the dataspace.
To understand the effects of AKPFREQ, three samples are reported, all using a CF-Structure log stream, although the results are equally applicable to DASD-only log streams. Figure 5-32 on page 193 shows the first sample's result where AKPFREQ was set to 7500, LGDFINT 00 and the log stream was connected to a 10M structure with HIGHOFFLOAD set to 80 and LOWOFFLOAD set to 50.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ___________________________________________________________________________________________________________________ (7) AKPFREQ 7500 LGDFINT 00 10M structure HIGHOFFLOAD 80 LOWOFFLOAD 50 08/25/03 1:55:00 PM (SMF INTERVAL TIMESTAMP 'B9EC872C55500000'X) IYOT1.CICS22.DFHLOG LOG_JG2_10M 332803618 571351296 137814804 1169531 951494 174502 43536 284 278135862 1004842 121753484 401533 324 18 0 **** 0 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames CF64 179.0 3550 65.04 65.04 .0063 0.1183 0.0068 0.1032 0.5 12.2 101.1 6.0 14906.1 8933 5973.1 Logstream Writes/sec: 2981.83
|
Figure 5-32: Example 4 - AKPFREQ set to 7500
Examination of the SMF Type 88 data reveals 121753484 bytes were deleted after being moved to the offload data set. The number of NTRY FULL conditions was so large it does not fit in the report -- symbolized by the ****. Both conditions suggest either the data residency time is too long or the log stream size is too small. If this log stream were a DASD-only, the symptom would probably be STG FULL.
For this reason, in the next sample, the following changes have been made:
-
CF structure storage size increased to 20MB
-
AKPFREQ value reduced to 4000
The results are shown in Figure 5-33.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ___________________________________________________________________________________________________________________ (8) AKPFREQ 4000 LGDFINT 00 20M structure HIGHOFFLOAD 80 LOWOFFLOAD 50 08/25/03 2:05:00 PM (SMF INTERVAL TIMESTAMP 'B9EC896889B00000'X) IYOT1.CICS22.DFHLOG LOG_JG2_10M 330844117 567308032 0 1159263 1147390 11873 0 285 330323643 1157378 0 0 302 0 0 0 0 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames CF64 173.7 3529 66.1 73 0.0053 0.1191 0.0069 0.1035 0.2 15.3 90.1 5.3 15286 8933 6353 Logstream Writes/sec: 3370.32
|
Figure 5-33: Example 5 - AKPFREQ set to 4000
Examination of the SMF Type 88 data for this sample shows data is no longer being deleted after having been moved to the offload data set, with no negative events. The number of initiated offload processes has decreased to 302, indicating better use of interim storage. This is the result of trimming the tail of the log stream more often, therefore making the offload process more efficient, that is, reaching the LOWOFFLOAD point without the need to move data to the offload datasets. Having 0 in the column 'BYT DELETD INTERIM ST W/DASD' means data which has been logically deleted by CICS was physically deleted, and the LOWOFFLOAD threshold was reached without further need of offloading data from the interim storage.
The System Logger TCB, SRB and APPL% remained constant for the period.
In the following sample, the AKPFREQ has been further reduced to a value of 2500 and you can observe the results in Figure 5-34:
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ___________________________________________________________________________________________________________________ (9) AKPFREQ 2500 LGDFINT 00 20M structure HIGHOFFLOAD 80 LOWOFFLOAD 50 08/25/03 2:15:00 PM (SMF INTERVAL TIMESTAMP 'B9EC8BA4BE100000'X) IYOT1.CICS22.DFHLOG LOG_JG2_5M 332796138 570890752 0 1167419 1155716 11702 0 285 332663638 1166945 0 0 243 0 0 0 0 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames CF64 178.9 3545 66.2 77.38 0.0053 0.1185 0.0069 0.1030 0.2 15.2 92.1 5.2 14844.5 8933 5911.5 Logstream Writes/sec: 3524.03
|
Figure 5-34: Example 6 - AKPFREQ set to 2500
The SMF Type 88 data show the results of trimming the tail even more frequently. The log stream continues to run very well. The number of offloads is even lower because in this case system logger probably was capable to go beyond the lowoffload threshold boundary while physically deleting the records that have been logically deleted during the more frequent AKPFREQ activity. As consequence, also the number of TYPE 2 writes is down, and there are no negative events recorded.
The System Logger TCB, SRB and APPL% remained constant for the period.
The offload value in the SMF 88 records is the number of times the offload process is initiated. Notice, there are no negative event indicators; all offloads are due to reaching the HIGHOFFLOAD point. Good offloads are those initiated because we reach the HIGHOFFLOAD value. Bad offloads are the ones which are the result of things like structure full, and so on.
The negative side of reducing the AKPFREQ value is it increases the number of CSKP transactions (activity keypoint) which run in the interval.
There is a balance point between the number of activity key points taken, the log defer interval and the size of the log stream interim storage. Each should be considered when evaluating log stream performance.
Not every region responds in this manner, so each region should be evaluated individually. The number of activity keypoints should also be monitored using the DFHRM0205 messages. The intent is not to cause an excessive number of CSKP tasks to run, but to optimize the log stream operation. In a busy region, a target of one activity keypoint every 40 to 60 seconds is good.
Also, each DFHRM0205 message should be accompanied by a DFHLG0743 message indicating the log is being trimmed. If log tail trimming is not happening consistently, the transactions active during the interval should be investigated to understand why syncpoints are not being issued.
| Tip | When changing the AKPFREQ (activity keypoint frequency) value using CEMT I SYS, it is best to make the changes coincide with an SMF interval, making it easier to evaluate the results of the change. |
Non-System Log Streams
User journals, forward recovery logs, and auto journals present a slightly different performance tuning opportunity. The data is always offloaded so the main considerations are interim storage residency time and how quickly the data can be offloaded.
The next samples show the effects of having a forward recovery log for one VSAM file in the region.
In sample 17 (Figure 5-35) there is a single CICS region, with DFHLOG allocated in a CF structure (LOG_JG2_20M). The region also has a forward recovery log (&applid..&SYSID..DFHJ03) for one of the files (FILEC). In the sample reported in Figure 5-35 the user journal was defined as a DASD-only log stream with STG_SIZE of 25000 4K CIs, which can hold 102.4M of data.
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ----------------------------------------------------------------------------------------------------------------- (17) AKPFREQ 1000 LGDFINT 0 20M HIGHOFFLOAD 80 LOWOFFLOAD 50 --- Forward Recovery Log STG_SIZE 25000 06/03/03 9:45:00 PM (SMF INTERVAL TIMESTAMP 'B984956CB0F00000'X) IYOT1.CICS22.DFHLOG LOG_JG2_20M 418554024 720508928 0 1480321 1475486 4836 0 282 421389900 1490611 0 0 90 0 0 0 0 0 0 IYOT1.IYO1.DFHJ03 *DASDONLY* 30473250 101478400 29913580 24775 0 0 0 1230 0 0 88190976 21531 2 0 0 0 268 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames CF64 215.3 4433 79.7 105.53 .0062 .1007 .0060 .0842 0.1 17.6 83.4 6.0 31757.0 12760 18997 3619.24 logwrites/second
|
Figure 5-35: User Journal - STG_SIZE 25000, single region
System Logger is issuing DASD I/O at the rate of 83.4 per second. DFHLOG is defined as a CF log stream. No data is being offloaded from DFHLOG and it does not have a staging data set. Therefore in this case, all DASD I/O is associated with the user journal.
The greatest impact to the system is the 18997 page frames (77M) allocated by System Logger to contain the data for both CICS log streams. To be technically accurate, there are three log streams, however DFHSHUNT is connected but no data is being written. Notice the excellent transaction rate (105.53 per second) with a response time of 0.1007 seconds.
DFHLOG is running very well, and in fact DFHJ03 is also working very well but you can see some differences between the log streams. For the user journal, since all data is offloaded, there should not be any information in the BYT DELETD INTERIM ST W/O DASD column. Likewise there should not be any data reported under #DELETES W/O DASD WRITE.
Under BYT DELETD INTERIM ST W/DASD will be the amount of data offloaded in the interval. Notice the number of STG THLD (the number of writes when the log stream was at or above the HIGHOFFLOAD threshold point) is over 130 times the number of offloads.
Because the log stream is so large CICS is able to issue 134 write requests in the time it take System Logger to perform the offload. Using the average buffer size shown (1230), means CICS is writing 164820 bytes while the offload process is taking place.
To determine if that's a problem we must determine how much space is available above the HIGHOFFLOAD threshold. STG_SIZE was specified as 25000 4K CIs, so using a HIGHOFFLOAD of 80%, the threshold point is at 20000 CIs. The storage above the threshold point is 5000 CIs or 20.48M. Since this is a DASD-only log stream and the average buffer size is less the 4K, there is room for 5000 writes before filling the staging dataset. Remember each buffer is rounded to a 4K CI boundary.
In the sample reported in Figure 5-36 the sizing formula discussed under "Forward Recovery Logs" on page 173 was used to calculate the STG_SIZE for the forward recovery log as 2549 (10.4M).
|
BYT WRITTN BYT WRITTN BYT WRITTN AVERAGE BY USERS TO INTERIM TO DASD #WRITES ---# WRITES COMPLETED------ BUFFER -LOGSTREAM NAME- STRUCTURE NAME-- IXGWRITES STORAGE INVOKED TYPE1 TYPE2 TYPE3 SIZE BYT DELETD # DELETES BYT DELETD # DELETS ---------------EVENT--------------- INTERIM ST W/O DASD INTERIM ST W/ OFF- DASD STRC NTRY STG STG RE- W/O DASD WRITE W/DASD WRITE LOAD SHFT FULL FULL THLD FULL BLD ----------------------------------------------------------------------------------------------------------------- (18) AKPFREQ 1000 LGDFINT 0 20M HIGHOFFLOAD 80 LOWOFFLOAD 50 --- Forward Recovery Log STG_SIZE 2549 06/03/03 10:20:00 PM (SMF INTERVAL TIMESTAMP 'B9849D3F68400000'X) IYOT1.CICS22.DFHLOG LOG_JG2_20M 445609444 767130624 0 1576179 1571029 5150 0 282 444776164 1573177 0 0 95 0 0 0 0 0 0 IYOT1.IYO1.DFHJ03 *DASDONLY* 29163300 97116160 31417260 23710 0 0 0 1230 0 0 93859840 22915 10 0 0 0 290 0 0 Type CICS DASD APPL% # Tran/ Average Average Average Average Logr Logr DASD APPL% Storage Idle Net TCB I/O Second CPU/Task Resp JC Wait File WT TCB SRB I/O Frames Frames Frames CF64 225.8 4720 83.3 112.36 .0061 .0921 .0061 .0751 0.1 19.1 79.9 6.5 22579.9 12044.2 10535.7 4533.17 logwrites/second
|
Figure 5-36: User Journal - STG_SIZE 2549, single region
Analysis of the data shows an increase in the offload number with an offload happening every 30 seconds, rather than every minute.
Compare the sample in "User Journal - STG_SIZE 2549, single region" on page 196 with the sample in "User Journal - STG_SIZE 25000, single region" on page 195. The staging data set allocation decreased and consequently the number of frames required by System Logger (10535.7 versus 18997) to back the data in the dataspace has been decreased. Also, since the staging data set is smaller, we are reaching the HIGHOFFLOAD threshold more often, therefore causing the additional offload.
"User Journal - STG_SIZE 25000, single region" on page 195 sample illustrates a common error, where the size of a user journal is defined to contain the same amount of data as a journal in a R410 system. The nature of user journals is they are never accessed by the online CICS region, so all data will be offloaded, that is, logtail management does not apply to user journals. As such there is little benefit in keeping the data in the interim storage; it's better to reduce the size (STG_SIZE) so offloads happen on a regular basis, and let the data reside in the offload data sets.
LS_SIZE should be specified large enough to contain the offloaded data during the prime processing period of the day.
Conclusion: STG_SIZE for user journals should be calculated and specified to provide a data residency time of one minute or less, therefore reducing the amount of storage required by System Logger to back the data in the dataspace.
|
| < Day Day Up > |
|
