Read B.01, B.10 & B.60 from the DB

[Michael A. Lowry]

Is there a way to read the B.01, B.10 & B.60 server process utilization values from the AE database?

[Jared Kessans]

Philipp Elmer put together a script that works nicely which I still use today.  Basically you run a script to collect the values but then you can then query the database for the collected values when needed.  You can see it in his blog post.

[Dominic Irudayasamy]

Is this possible to get the value for each WP and CP?

------------------------------
Dominic I
------------------------------

[Michael A. Lowry]

The performance monitoring solution must be independent of the Automation Engine, and able to monitor the AE system effectively even when the AE is experiencing problems that interfere with processing of active tasks. This is why I was looking at a pure SQL approach.

The AE clearly does more than just calculate the B.01, B.10, and B.60 values on-demand. It must also store them somewhere so that it can provide per-process statistics as well as system averages for each time interval. This raises two questions:

1. How does the Automation Engine calculate B.01, B.10, and B.60*?
2. Where does the AE store historical utilization values for the table & histogram shown in the AWI?

* One more question just to satisfy my curiosity: For what does the B in these fields stand? Belastung?

[Michael A. Lowry]

@Markus Embacher with Broadcom Support kindly provided answers.

1. KB article 88019 describes, in general terms, the way the Automation Engine calculates AE server process utilization. An AE server process is considered busy any time it is not idle. Busy time includes time used by DB, network, and the AE server process itself.
2. Each AE server process stores in memory its own statistics for the previous 24 hours. Averages are calculated using these in-memory data. These statistics are not stored in the AE database.

[Krum Ganev]

Not really.
This info is calculated real time and not stored anywhere.

Ive played around with SYS_BUSY_* and SYS_INFO but with no avail.
the SYS_BUSY_* return the info only for the WP where that call is actually executed.
In system with many WP's this is no help at all.

SYS_INFO allows you to chose between PWP, OWP, RWP and WP but fot the WP's is again the same. You can not be specific.
Hence the actual use of that (for the WPs ) is close to none.

------------------------------
------------------------------
Automic SME @ DXC.Technology
------------------------------
------------------------------

[Jared Kessans]

It has helped us in the past when we were getting extremely high utilization during certain times causing performance issues.  It helped us track down the cause which turned out to be another group running their database maintenance during primary batch times.  Their database resided on the same cluster node as ours.  Our DBAs then moved that team's database to a different node. 

This was just one example, so it can help.

[Marcin Uracz]

If you are interested in the general load values, the metrics are stored in the PMMA, PMMAV tables if you have the PERFORMANCE_ACTIVE set to Y in UC_SYSTEM_SETTTINGS.

select pmmav_key,pmma_timestamp, pmmav_value from pmma 
join pmmav on pmma_idnr = pmmav_pmma_idnr
where pmma_pmmd_idnr = 6

   This should give you the metrics in one minute resolution. 

I ingest this data (accually now collected via REST API ) to a timeseries DB (influx) and do the aggeration there. 

------------------------------
Cheers,
Marcin
------------------------------

[Michael A. Lowry]

Hi, @Marcin Uracz. Thanks for letting me know about the option to log performance statistics. That is very useful.

In the the German documentation, the parameter is called PERFORMANCE_ACTIVE as you stated.

In the English documentation however, the parameter is called PERFORMANCE.

In my testing, I found that these two parameters are interchangeable. That is, the AE accepts either parameter. Would someone from Broadcom Support please confirm this?

The documentation related to performance parameters actually needs several corrections:

1. Even if both PERFORMANCE_ACTIVE and PERFORMANCE are accepted by the AE, the documentation should be updated to list only one of them consistently, or to list both.
2. The parameters PERFORMANCE_CHECK_INTERVAL and PERFORMANCE_MEASURE_INTERVAL are undocumented. These parameters appear to refer to the same thing. In any event, this should be documented. (And like above, if the two parameters are interchangeable, one of them should be used consistently, or they should both be documented.)
3. The AE does not recognize the parameter PERFORMANCE_CLEAN_UP_BATCH_SIZE. The correct parameter appears to be PERFORMANCE_CLEANUP_BATCH_SIZE, without an underscore between CLEAN and UP.
4. For PERFORMANCE_CLEANUP_BATCH_SIZE, the Allowed values listed are 1 to N. My testing revealed that the maximum is 900. This is also the default.
5. For PERFORMANCE_KEEP_DAYS, the Allowed values listed are 1 to N. My testing revealed that the maximum is 2147483647*. The default is 30.

Ping @Gabi Oberreiter.

* 2147483647 is 2³¹ - 1, the largest integer that the Automation Engine is able to handle. This number of days corresponds to nearly 5.9 million years.

[Michael A. Lowry]

Broadcom quickly updated the English documentation last week to refer to the parameter as PERFORMANCE_ACTIVE, as in the German documentation.

The other documentation problems remain to be fixed.

[Keld Mollnitz]

We would also want to proactively monitor this from outside Automic.

And yes, you can see the B.01, B.10, B.60 for each server process in the AWI, so it should be possible to get those same numbers directly by querying the database.
Someone from Broadcom should have this knowledge and be able share it with us.