CPU usage of proxy TEMS is high

Technote (troubleshooting)


Problem(Abstract)

Your TEMS acting as Sysplex Proxy is consuming a very high amount of CPU because of an high activity to collect Coupling Facility (CF) data

Environment

There are two basic types of situations. The first type is the standard status-reporting situation that can turn on warning and critical indicators at the portal and can drive action commands.
OMEGAMON XE on z/OS includes several of these situations as part of the product installation. You might have added more situations.
The second type of situation is special UADVISOR situations that are used by OMEGAMON XE on z/OS to migrate data from remote monitoring servers to the Sysplex Proxy.
Such process to migrate data from remote monitoring servers to the Sysplex proxy means that basically we pickup the single measurements for any single agent part of the Sysplex and then, merge and consolidate together so to offer data at sysplex level; this is a very high consuming process causing a lot of overhead for your TEMS Proxy Sysplex Proxy.
The additional note on this is that NO CF situation should ever have an interval of less than 5 minutes. The data is gathered every 5 minutes, so any situation that runs with an interval less than that is just reporting the same data over and over again.

Diagnosing the problem

You may execute the following steps to catch which are the situations managing Coupling Facility (CF) data :

1.1)Define following member (you may call it TSITDES2 in your RKANSQL/RKANSQLU dataset):

EDIT OMEGA42.RTE41.RKANSQLU(TSIDES2) -
Command ===>
****** ***************************** Top of
==MSG> -Warning- The UNDO command is not ava
==MSG> your edit profile using the
000010 SELECT SITNAME,
000020 TEXT,
000030 REEV_TIME,
000040 PDT
000050 FROM O4SRV.TSITDESC
000070 WHERE PDT LIKE "*CF*";

1.2)Execute following command to retrieve the Situations defined in your RTEMS

/F CANSDSST,CTDS START SPUFIL,TSITDES2
/F CANSDDST,ECHO FLUSH

where CANSDSST is the STC name of your TEMS

1.3)You may provide me the RKLVLOG by having ensured (look for string "SPUFIL") that you get an output like this:

2013.004 14:54:20.16 KLVOP191 'CTDS START SPUFIL,TSIDES2'
2013.004 14:54:20.16 Local Path is .... CT/DS:àSERVER=SRVR01 USERID=DSTSLCè
2013.004 14:54:20.17
2013.004 14:54:20.17 Library Name:
2013.004 14:54:20.17 Member Name: TSIDES2
2013.004 14:54:20.17
2013.004 14:54:20.17 SELECT SITNAME,
2013.004 14:54:20.17 TEXT,
2013.004 14:54:20.17 REEV_TIME,
2013.004 14:54:20.17 PDT
2013.004 14:54:20.17 FROM O4SRV.TSITDESC
2013.004 14:54:20.17 WHERE PDT LIKE "*CF*";
2013.004 14:54:20.17
2013.004 14:54:20.17 /*********************************************/
2013.004 14:54:20.17 /********** Create Request Was Done **********/
2013.004 14:54:20.17 /*********************************************/
2013.004 14:54:20.17
2013.004 14:54:25.17 test_fra
2013.004 14:54:25.17 test pmr xxxx,xxxx,xxxx
2013.004 14:54:25.17 000500
2013.004 14:54:25.17 *IF *VALUE XCF_Members.Group_Name *EQ 'SYSMCS' *AND *VALUE XCF_Members.Member_Name *EQ 'ZOS1659' *AND *VALUE XCF_Members.Status *EQ Missing

The above queries will retrieve all the situations that contain string XCF in the predicate and so a good estimation of all the situations you are running managing the CF data. The value for REEV_TIME is the one you need to specify to at least 5 minutes.

Resolving the problem

Ensure that all situations managing Coupling Facility data have a collection interval equal or greater than 5 minutes.

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Tivoli Management Server for Distributed Systems on z/OS

Software version:

6.2.2

Operating system(s):

z/OS

Reference #:

1621672

Modified date:

2013-01-08

Translate my page

Machine Translation

Content navigation