That table is used internally for usage tracking purposes that could aid in troubleshooting.  The data does not need to be persisted long term though, so if you are finding that it is consuming too much storage in the database, you can safely truncate the table periodically without fear of doing harm elsewhere.

Good to know thatmx_u - can be truncated. Any sort of recommendation on what frequency and how many months of data should be stored?

Please be advised of the following note from the FSM6U11 Release Notes.

ANALYZE USAGE MPM
The MX_U table has been enhanced with new columns to track the time messages take to execute, and also detect any messages that are received but do not complete. A new MPM called perform_analyze_usage can be called to analyze the usage, summarized in the MX_U_R table. The MX_U table is now truncated on upgrade, and data saved is limited to 30 days.

If this data is not being used, a Scheduled Process can be configured to delete the data that’s more than X days old.

In my opinion we should at least have a setting or parameter available that allows us to disable the generation of MX_U records. 

The data generated in an high volume production environment can be enormous. 

Yes we can truncate the data in MX_U, but we should ask ourselves whether this data is really needed and how often has it been used for analysis before?

In case there are a lot of records in the MX_U table calling perform_analyze_usage can cause a significant performance issue. 

This is because the analyze usage selects all data in memory dataset. 

Perform_analyze_usage should be called specifying a narrow time range for the period of interest, such as the period of hours leading up to an outage.  It is not intended to be used to analyze months of usage.  Also do not use during the day in a busy production system.   We’re evaluating what we can do to lessen the impact of this facility.

R&D explained, “Every external message coming in to the FSM Server (smart client, web client, mobile, integrations, PSO) gets a record in MX_U.  With another customer, we’ve seen that truncating MX_U did not make a dramatic difference in performance; it was rather fixing the issues with their implementation that made the difference.  There are numerous configuration elements that if inefficiently constructed can cause performance issues, including Business Rules, Integration Maps, etc..  The Customer's configuration needs to be thoroughly reviewed to identify the cause.  In one case for another customer, a badly constructed custom view was the actual problem.”

This feature is being enhanced with the ability to specify a particular time frame for the investigation, as well as the ability to completely disable the data collection by setting the USAGE_DAYS_TO_SAVE App Param to ‘0’.  This is currently planned for delivery in Update 16, which is scheduled for release in late February, 2022.

@ruben.maas 

@TatKhandM 

@Lee Pinchbeck 

@Ann Degroat 

Further to the enhancements which will be delivered in Update 16 (see above),  in Update 17 we have enhanced the deletion based on USAGE_DAYS_TO_SAVE to delete rows in MX_U in small batches to ensure deletion completes.

@ruben.maas

@TatKhandM

@Lee Pinchbeck

@Ann Degroat