Technical Blog Post
MQ Monitoring agent: CPU usage
Monitoring overhead for the MQ monitoring agent is affected primarily by the numbers of MQ objects you are monitoring.
It is important not to enable monitoring for data that you never use.
For data that you do use, you can affect the overhead by using several parameters available for the MQ monitoring agent.
Below are some general things to consider that affect CPU/Storage:
1) Sampled Versus On-Demand
The MQ monitoring agent collects data by sampling on a timed interval basis or by querying on-demand in real-time. Therefore, attribute groups provided by the agent are characterized to be "sampled" or "on-demand".
Queries to sampled attribute groups will return the values collected during the sample interval processing. Use this data for regular monitoring, recent trends and historical collection. Report and situation queries to this data generally perform the best, but remember that the overhead related to collecting this data is constant (per sample interval).
Queries to on-demand attribute groups will return values collected at the moment of the query. Use this data when you need the most current, real-time metrics. Report and situations queries directly incur the overhead related to this data. However, the overhead is only constant when a situation uses the data or when a workspace is set to auto-refresh.
2) Reduce Monitored Queues
When there are a large number of queues in a queue manager, you can reduce CPU overhead by reducing monitored queues to just those important to you. Use the SET QUEUE agent parameter statement to specify just
those names or name masks that you want to monitor.
For example, SET QUEUE NAME(SYSTEM.*) specifies to only monitor the SYSTEM queues. You can specify multiple SET QUEUE parameter statements to allow specifying several names or name masks. An example full SET
QUEUE statement is:
SET QUEUE NAME(SYSTEM.*) QDEFTYPE(PREDEFINED,PERMDYN) GROUP(DEFAULT)
Various parameters on the SET QUEUE statement also allow limiting which queues to monitor without considering the names of queues. These parameters therefore also allow reducing data collection overhead related to queues.
QDEFTYPE(PREDEFINED|PERMDYN|TEMPDYN|ALL) defaults to PREDEFINED in order to avoid increasing the amount of queue data sampled and maintained for dynamic and temporary queues.
QTYPE(ALL|QLOCAL|QALIAS|QCLUSTER|QREMOTE|QMODEL) allows the agent to only sample data about certain types of queues. Multiple types can be specified for QTYPE, separated by commas. For example, if the numbers
of alias queues is quite high by comparison, removing alias queues from collection could help alleviate the need to specify names or name masks on SET QUEUE statements. Since alias queues just provide a different
name for local queues, you will not be missing critical data like about the queue depth.
3) Cleanup Unused Queues
When there are a large number of queues in a queue manager, you can reduce CPU overhead by removing queue objects that are no longer needed in your environment.
4) Check Situation Intervals
Review the interval setting for situations distributed to the monitoring agent, since the situation interval settings can affect CPU overhead. This is especially true when the situation pertains to large numbers of
objects in the queue manager, like when there are a large number of queues.
For "sampled" data attribute groups used in situations, there is no need to have a situation interval that is more frequent than the SAMPINT agent parameter setting. The sampled data will not change more
frequently than the sample interval.
For "on-demand" data attribute groups used in situations, the situation interval dictates how frequently the agent queries and processes that data from the queue manager, so has a direct impact on overhead.
4) Increase SAMPINT
When the agent sample interval is low, the CPU overhead of the agent will be higher. The SAMPINT agent parameter on the PERFORM STARTMON statement indicates how frequently the agent will sample data from the
queue manager for any of the "sampled" attribute groups (see previous subsection).
The default in recent releases is 5 minutes. However, if that is not an acceptable setting, even changing from 1 minute to 2 minutes will cut overhead related to sample processing in half. Note that the SAMPINT
value is in seconds, so the default is SAMPINT(300).
When using on-demand data for real-time problem determination, you can run with a larger SAMPINT value, since the sampled data then is used more for trending and historical collection.
5) Reduce Monitored Channels
When there are a large number of channels in a queue manager, you can reduce CPU overhead by reducing monitored channels to just those important to you. Use the SET CHANNEL agent parameter statement to
specify just those names or name masks that you want to monitor.
Note that SET CHANNEL does not affect on-demand attribute queries, so even if you do not sample data about particular channels, you still can get the most current data for a channel by using an on-demand attribute
6) Historical Data Collection
Only enable attribute groups for historical collection if you actually will use that historical data.
7) Limit Recent Data Retention
For sampled data, the agent retains in storage several recent samples, which is used to populate "Recent" workspaces. The default is 15 samples. If you collect historical data, you may not even need 15 samples retained for recent reporting, so you can consider lowering this value. Use the AGGRHIST agent parameter on the SET GROUP statement to modify this setting.
Subscribe and follow us for all the latest information directly on your social feeds:
|Academy Twitter :||https://goo.gl/AhR8CL|