You may want to keep more data with a longer history of time intervals in the Java Performance Monitoring.
For example, you want to keep the daily intervals for 14 days instead of only 7 days.
For PI releases 7.31/7.4, the enhancement was introduced that allows extension of retention period for persisted performance data. You can call the following servlet and set custom value of the retention period using the URL parameter PeriodConfig of PerformanceDataQueryServlet.
http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=...
The following period types are supported:
- MINUTE: performance data for last 1 hour, aggregated per 15 minutes;
- HOURLY: performance data for last 24 hours, aggregated per 1 hour;
- DAILY: performance data for last 7 days, aggregated per 1 day.
For example,
1) If you'd like to see the performance data per day in the past 14 days in the Performance Monitor tool, you can use the servlet:
http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=DAILY=14
(14 = 14*1)
2) If you'd like to see the performance data per hour in the past 30 days in the Performance Monitor tool, you can use the servlet:
http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=HOURLY=720
(720 = 30*24)
3) If you'd like to see the performance data in the last 24 hours with 15 minutes interval in the Performance Monitor tool, you can use the servlet:
http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=MINUTE=96
(96 = 24*4)
4) You can also change all interval types with one servlet call and don’t have to call it 3 times:
http://<host>:<port>/mdt/performancedataqueryservlet?PeriodConfig=DAILY=14,HOURLY=720,MINUTE=96
Note: If you call this servlet (HOURLY=720), it means "keep the hourly intervals for 720 hours(30 days)", not "keep 720 hourly intervals". The URL parameter PeriodConfig defines the retention period for performance data displayed in performance monitor tool, not the number of intervals displayed there. An interval only appears if there are actually messages in this interval. For example, if you don't have messages in the night, then some hour intervals might not appear.
Note: The new, customized values are persisted to database and survive a system restart and deployment of updates and upgrades. But if the performance data collection was disabled (parameter profile.performance.runtime of the service "XPI Service: AF Core" as described in note 1636215) and again enabled, then the values are reset to the default (DAILY=7, HOURLY=24, MINUTE=4).
Note: Keeping too many entries can cause the respective database table to grow. So you should always adjust the number of kept entries to the required minimum and consider to export them to a remote database or file. The number of entries/rows in the table can be calculated with the following formula:
Rows = Nr. of Server Nodes * PI Scenarios * (daily + hourly + minute)
So if you keep 96 of the 15-minute intervals and 720 of the 1-hour intervals and 14 of the 1-day intervals, that means 830 entries. This 830 is then multiplied by the number of scenarios and the number of server nodes, for example, if you have 1000 scenarios and 10 server nodes, then you will have 8.3 million entries in the DB table XI_AF_PROF_PERF_AC.
************
Also you may want to know if parameter profile.performance.cache.cleanup is relevant to the data retained time in performance monitor tool. The answer is no.
Some background information:
1) Performance Monitor first keeps non-final messages in a memory cache. Those are messages in Delivering, To Be Delivered, System Error and Waiting.
If there are too many non-final messages piling-up in the memory (e.g. some PI scenario fails and there are thousands of System Error messages in the system), the so far collected performance data for the non-final messages are swapped-out from the memory cache to the DB table XI_AF_PROF_PERF_CA to prevent unlimited growth of the memory cache and out-of-memory errors.
The parameter "profile.performance.cache.cleanup" now controls, after how many days the old data is deleted from the DB table XI_AF_PROF_PERF_CA. Please note that this data is only for the non-final messages, which are not part of what we can see in the Performance Monitor tool.
2) If the message goes into a final status (Cancelled or Delivered), they are removed from the memory cache and aggregated into the final data sets. Those Performance Data is summed-up in an aggregated data entry according to the time intervals.
Those aggregated data is stored in DB table XI_AF_PROF_PERF_AC (please note that the table name here is different from the previous one) and this is the data we can see in the Performance Monitor tool. How long we keep this aggregated data can be changed with the servlet above.
Related Content
Note 2006366 - Performance Monitor: change number of retained time intervals
Note 1993988 - Performance Monitor: improvements and fixes for Java PerfMon 2
Note 1790113 - Performance Data: automatic query of data with a servlet
External Collection of Message Processing Statistics from Advanced Adapter Engine of PI