Governor
A governor in z/OS is a system mechanism designed to control and limit the consumption of specific resources (e.g., CPU, I/O, elapsed time) by workloads, address spaces, or individual transactions. Its primary purpose is to prevent runaway processes, ensure system stability, and enforce service level agreements (SLAs) by managing resource contention.
Key Characteristics
-
- Resource Limitation: Can limit various resources including CPU time, I/O operations, elapsed time, memory usage, and transaction rates.
- Policy-Driven: Configured through policy statements within specific subsystems or the Workload Manager (WLM), defining thresholds and actions.
- Preventive and Corrective Actions: When thresholds are exceeded, governors can take actions such as delaying execution, terminating tasks (e.g., an abend), or issuing alerts.
- Subsystem Specific: Often implemented within specific subsystems like CICS (e.g., transaction class maximums, run-away task detection), DB2 (e.g., DSNZPARM settings for query limits), or IMS.
- Workload Manager (WLM) Integration: Works in conjunction with WLM, which provides the overarching performance goals, while governors enforce finer-grained resource limits within those goals.
- Granularity: Can apply limits at various levels, from an entire address space to specific transaction types or even individual database queries.
Use Cases
-
- Preventing Runaway CICS Transactions: Limiting the CPU time or database calls for CICS transactions to prevent them from monopolizing resources and impacting other online services.
- Controlling DB2 Query Execution: Using DB2 governors to terminate or delay SQL queries that exceed predefined CPU, I/O, or elapsed time limits, safeguarding database performance.
- Enforcing Batch Job Resource Ceilings: Capping the CPU usage or elapsed time for non-critical batch jobs to ensure they do not consume excessive resources during peak online processing hours.
- Resource Isolation for Applications: Providing dedicated resource ceilings for different applications or tenants sharing the same z/OS LPAR to ensure fair resource distribution.
- Managing IMS Transaction Performance: Limiting the number of database calls or CPU time for IMS transactions to maintain predictable response times.
Related Concepts
Governors are a critical component of z/OS Workload Manager (WLM), which defines the overall performance goals and resource distribution policies across the system. While WLM manages the dispatching priority and resource allocation to meet goals, governors provide the enforcement mechanism for hard limits within specific subsystems. They complement Resource Measurement Facility (RMF) and System Management Facilities (SMF), which monitor resource consumption, by actively intervening when defined limits are breached.
- Start with Conservative Limits: Implement governors with less restrictive limits initially and gradually tighten them based on performance monitoring and analysis.
- Monitor and Tune Continuously: Utilize tools like RMF, SMF, and subsystem-specific monitors (e.g., OMEGAMON for CICS/DB2) to track governor activity and adjust settings as workloads evolve.
- Define Clear Actions: Ensure that the actions taken by the governor (e.g., abend, delay, message) are appropriate for the workload and have minimal unintended side effects on system stability.
- Document Policies Thoroughly: Maintain comprehensive documentation of all governor settings, their rationale, and the expected impact to facilitate troubleshooting and future adjustments.
- Test in Non-Production: Always test governor configurations extensively in a non-production environment to validate their behavior and prevent unexpected outages or performance degradation in production.