II09294: CONSIDERATIONS FOR COUPLING FACILITIES THAT RUN IN SHARED LOGICAL PARTITIONS

APAR status

• Closed as canceled.

Error description

• SEARCH ARGUMENT = SYSPLEXINFO SYSPLEXDS DB2INFO
  
  ****************************************************************
  * This APAR contains the following:                            *
  *                                                              *
  *  Considerations for Coupling Facilities that run in shared   *
  *  Logical Partitions (LPs):                                   *
  *                                                              *
  *   - Recommendations for Coupling Facilities (CFs) with CFR   *
  *     Channels (non-ICMF).                                     *
  *                                                              *
  *   - Recommendations for Coupling Facilities that use the     *
  *     Integrated Coupling Migration Facility (ICMF).           *
  *                                                              *
  * For additional information on "LPAR Performance              *
  * Considerations for Parallel Sysplex Environments" see        *
  * Washington System Center Flash 9609.                         *
  *                                                              *
  ****************************************************************
  
   Recommendations for Coupling Facilities with CFR Channels:
  
    The CFCC code that runs in a CF logical partition, uses a
    polling loop to find new work. The "active wait" polling
    algorithm employed by the CFCC does not fit well into an
    environment that wants to share CP resources.  The demanding
    response time requirements put on the CFCC in conjunction with
    there being no hardware interrupts available to signal the
    arrival of new work make polling a necessity. Polling causes
    the CF to use as much CP resource as it can get, mostly while
    looking for work. The CF then almost always looks like the
    worst choice for PR/SM dispatching next in a contention
    situation since it always uses the CPU. The advantage of PR/SM
    LPAR is its event driven dispatching function that allows for
    balancing of CP resources across multiple logical partitions.
    In the case of coupling facilities, there are no "events".
  
    Because of this, THE RECOMMENDATION FOR CFs IS TO DEDICATE
    CP(s) TO THEM.
  
    If you want to run a CF in a logical partition with shared
    CP(s), You must be willing to give horsepower to the CF.
  
    The PR/SM Planning Guide lists guidelines for setting up a CF
    logical partition to use shared CPs. Please refer to these
    guidelines.
  
    There is an error in PR/SM Planning Guide GA22-7123-12.  It
    states that the weight of the CF logical partition should be
    set so that the CF logical processors are, at a minimum, equal
    to the weight of the logical processors for the MVS systems on
    the CPC that the CF is serving. This recommendation may not
    produce the desired results in some environments. Use the
    following guidelines when defining CFs in shared LPs:
  
    - Choose a weight for the coupling facility LP based on the
      anticipated CP requirements of the coupling facility.  When
      deciding how much CP resource should be given to each
      coupling facility logical CP, consider the following:
  
      o CP resource requirements will vary depending on the
        coupling facility exploiter functions and your sysplex
        hardware and software configuration.  When the anticipated
        CP requirement of the CF is less than one physical CP; as
        a general guideline, set the weight of the coupling
        facility LP so that the coupling facility logical
        processor has 50% or more of a PHYSICAL CP.  If you have
        less than a full PHYSICAL CP allocated to the coupling
        facility logical processor, this will result in some
        elongation of response time.
  
        Examine the RMF "Coupling Facility Activity Report" and
        tune the coupling facility LP weight until your
        performance requirements are met.
  
        Note: When examining the RMF "Coupling Facility Activity
              Report" you may see elongated average response
              times.  Usually these are accompanied with high
              standard deviations as well. This indicates most
              requests are in the expected range with an
              occasional very elongated response that skews the
              average.
  
      o Give more weight to the coupling facility LP for functions
        that have more stringent responsiveness requirements.  For
        example, you should set the coupling facility weight
        higher for coupling facility exploiter functions such as
        IMS/IRLM. For IMS/IRLM, you may want to set the weight of
        the coupling facility LP so that each coupling facility
        logical CP runs almost dedicated.  For example, you may
        want to set a weight that will give each coupling facility
        logical CP 90% or more of PHYSICAL CP resources.
  
        Less weight may be required for coupling facility
        exploiter functions such as IEFAUTOS, which is used in
        controlling automatic tape switching.  For example, if
        your coupling facility is being used exclusively by the
        automatic tape switching function, your coupling facility
        responsiveness requirements may be less stringent.  If
        this is the case, you may choose to allocate less PHYSICAL
        CP resource to the CF LP so that, for example, the
        coupling facility logical CP receives 40-50% of a PHYSICAL
        CP.
  
        Generally, functions involved in datasharing are more
        CF-operation intensive and have higher responsiveness
        requirements, and so they demand a higher CF weight.
        Structures used in a datasharing environment include:
  
          - IRLM lock structure for IMS
          - IRLM lock structure for DB2
          - IMS OSAM cache
          - IMS VSAM cache
          - DB2 group bufferpool cache(s)
          - System Logger (if used by CICS)
          - RACF cache(s)
          - XCF signalling
  
        Generally, functions not directly involved in datasharing,
        i.e. the sysplex management and single-system image
        functions,  require less responsiveness and thus less
        weight for the CFs that contain them. Structures that fit
        into this category are:
  
          - System Logger (Operations Log, Logrec)
          - JES2 checkpoint
          - DB2 SCA
          - VTAM generic resources
          - Shared tape
  
        The categories of structures listed above are
        generalizations.  Actual responsiveness requirements will
        vary depending on your environment.
  
      o As the total traffic (requests per second) to the coupling
        facility increases, there is a greater need for real
        coupling facility CP time. To a point, the increase in
        traffic may not require an increase in the coupling
        facility LP weight.  This is because CF active wait time
        turns into CF busy time.  You must monitor coupling
        facility utilization and adjust the LP weight to ensure
        that your performance requirements are being met.
  
      o NEVER cap a CF logical partition.
        -----
        NOTE: Given the fact that your coupling facility logical
              partition runs UNCAPPED, it may use more CPU
              resource than is indicated by the weight of the
              logical partition.  As the load on the non-CF LPs
              increases, PR/SM will decrease the amount of
              PHYSICAL CP resource given to the CF LP.  For
              example, assume that your CF LP is weighted such
              that it is suppose to receive 50% of a PHYSICAL CP.
              Also assume that the non-CF LPs on the CPC are
              under-utilized thereby allowing the CF LP to run
              with 100% of a PHYSICAL CP. If the load on the
              non-CF LPs increases, the CF LP PHYSICAL CP
              utilization may be decreased to 50% of a PHYSICAL
              CP.  You must be prepared to compensate the CF
              logical partition with more PHYSICAL CP resource if
              needed.
  
      o Keep the number of logical CPs defined to the coupling
        facility logical partition to a minimum.  If you
        over-define logical CPs for a CF, you end up having those
        CPs competing with each other for cycles. Most of these
        cycles are spent looking for work. More logical CPs
        (beyond the actual busy needs of the CF) actually hurt a
        CF configuration with shared CPs.
  
    If you can accept slower response times or occasional slower
    response times and the load is not too great, CFs in shared
    LPs may be a viable alternative to running CFs with DEDICATED
    CP resources.
  
  
    What can go wrong if a CF using shared CPs does not have
    enough processing weight ?
  
    o Insufficient processing weights may result in elongated
      response times on requests to the coupling facility.  The
      times when MVS sends a request to the CF when the CF does
      not happen to be dispatched, will naturally result in a
      longer request time because MVS has to wait for the CF to
      get dispatched by PR/SM.
  
    o If a request to the CF takes more than 300 milliseconds, the
      request will be timed out and reported to MVS. These show up
      in MVS LOGREC as interface control checks. They are
      functionally harmless as MVS will respond to this by
      re-issuing the request.  The result however is yet further
      elongated response time for the original request.
  
    o Insufficient processing weights may result in time-outs that
      span a time of about 3.5 seconds. At this point MVS will
      consider that path to the CF as being broken. If other paths
      are available, MVS will try those. If all paths are
      "broken", MVS will declare a loss of connectivity to the CF
      and start recovery actions.  Those actions are signalled out
      to the subsystems using the CF and they must take action to
      recover; usually a rebuild of data in another CF. MVS then
      will poll the "broken" paths every so often to see if it
      comes back. If this happens quickly enough (prior to
      rebuilds elsewhere), the CF will be recovered with all its
      data intact.  Otherwise, if CF connectivity is reestablished
      after recovery actions are complete, the CF simply becomes
      an available CF with no data in it.
  
  Recommendations for Coupling Facilities that use the Integrated
  Coupling Migration Facility (ICMF):
  
    The ICMF Dispatching Enhancement should be installed. It is
    available on the following CPCs:
  
    - 9672 R2 and R3 CPCs (all ECs)
    - 9672 R1, E, and P CPCs at EC D57262
    - 9021 711-based CPCs at SEC 236422 (with LIC patch support)
    - 9121 511-based CPCs at SEC C35956
  
    The ICMF dispatching enhancement reduces the system overhead
    associated with running a coupling facility LP that uses ICMF
    and shares the CP resource.
  
    Unlike a non-ICMF coupling facility, a CF that uses ICMF with
    the dispatching enhancement in a shared LP will give up its
    logical CP share to other LPs running on the same CPC when
    there is no coupling facility work pending (i.e. The
    dispatching enhancement has eliminated the ICMF coupling
    facility "active wait").  This ensures that more CP resource
    remains available to other LPs running on the same CPC by
    preventing unnecessary use of CP cycles by a CF logical
    partition using ICMF.  It is therefore not necessary to
    dedicate CP resources to the coupling facility LP that uses
    ICMF with the dispatching enhancement.  NOTE: The dispatching
    enhancement only applies to CFs that use ICMF.
  
    When running a CF that uses ICMF with the dispatching
    enhancement in a shared LP, consider the following:
  
      - In a production environment, capping the CF LP is not
        recommended.  If the CF requires more CP resources than is
        permitted given its defined weight and the CF LP is
        capped, responses to CF requests will be delayed. Delayed
        response times may affect all MVS images that the CF
        serves.
  
      - The number of CF logical CPs and the weight of the CF
        logical partition depends on the frequency and
        responsiveness requirements of CF requests. The coupling
        facility LP should be defined based on these requirements.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• close for Internet viewing
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels