On Fri, 12 Oct 2007 15:05:32 -0400, Lizette Koehler <[EMAIL PROTECTED]> wrote: -snip/edit- >I forgot to add we share all dasd. So everything can see everything. >5 LPAR Parallel Sysplex (2 Prod/2 Devl/1 Sysprog). >2 Physical boxes, and one ICF on each box. >z9 has 3 LPARs, 1 Prod, 1 Devl, 1 Sysprog >z890 has 2 LPARS, 1 Prod, 1 Devl >One is a z9 (3 engines) and the other a z890 (3 engines). >GRS=STAR. >One master cat and one sysres set. >Share all dasd.
In Star mode, GRS uses up CPU in proportion to the demands on the function. If no ENQ/DEQ/GQSCAN/ISGQUERY requests arrive, there is very little 'background noise' to drive any CPU utilization. Things to look for in a spike situation: A burst of contention for global resources: - To resolve, the systems involved need to send XCF signals to a contention managing system (for that resource, designated by XES - visible in a dump) and is followed up by activity in the GRS Contention Notification system (visible from D GRS) to signal monitoring software of the event (ENF51). A burst of global GQSCAN/ISGQUERY activity: - Depending on the kind of GQSCAN, a large number of XCF signals will be exchanged between systems and then the requesting system will parse and build the results. A burst of global ENQ activity in a system with 'slow' response time from the CF: - By default, lock requests are issued synchronously to the CF (over time, XES will watch behaviors to determine if requests should be converted to asynchronous), so XES 'spins' the CPU in the requesting address space (GRS) waiting for the results from the CF request. If these times are relatively long, it will appear that the system is spending additional time in GRS. Scott Fagen Enterprise Systems Management ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
