TRIM 7.2.1 - Event Processing is slow after upgrade from 6.2.x, this cause major performance issue

Hi Gurus,


3 months ago the company that I worked for upgraded TRIM from version 6.2.x to 7.2.1. After the upgrade, everything seems to be fine until recently the event processing are stuck with initializing and after 5 hours, I only can see 500 events out of 400K events are processed.


Besides, due to this the performance of TRIM is incredible slow. After turning off the service through TES, the performance improved again.


HP suggested to let the event processed but we had let it run for almost 3 months and it is still have 400K events. Any suggestion or sharing for this on what should I do to move forward?

Parents Reply Children
  • Hi Grundy,


    Your prediction is correct. During the upgrade the support team had missed out one of the steps in converting the old schema to the new one which resulting to this huge backlog included for the past 3 months.


    We are trying all the possible ways by converting the schema and configuring the processing and still the rate is super slow. We have doing it for a week now (from 63 millions to now 60 millions).


    Appreciate for your sharing to assist us in proceeding further?

  • In the TRIM/RM Enterprise Studio, go to the Dataset > Event Processing > Configure > Options.

    Start by setting the batch size to 3000 and polling interval to 60 seconds.


    Save and deploy this change and restart the Workgroup Service.


    Watch the event processing queue closely and see if the number of events processing is increasing by 3000 every 60 seconds.

    If they aren't reaching 3000 processed by 60 seconds, it means that the polling interval will take another 60 seconds before it grabs the next 3000 events to process, so it's best to find a balance by slightly increasing the polling interval or decreasing the batch size (e.g. 60 seconds and 2000 events)


    The default values of 500 events every 120 seconds is very slow and most databases will be able to cope with much more. (NOTE FOR ORACLE USERS, ORACLE has a limit of 1000 events due to a limitation with the IN clause...)


    Have you also looked at whether you can delete any redundant event rows?

    e.g. delete all events where age/uri is less than 3 months ago?



  • Hi,


    I am not sure if the thread going on here is posted by any of my team member, (Seems almost like our issue). ;)


    We are, in our company also have a smiliar issue, we had upgraded TRIM from 6.25 to TRIM 7.2.1 3519 Build almost 7 months ago. And since after the upgrade we saw similiar issue like you have, like Events processing was very slow and TRIM performance as well was very poor, we engaged HP team and almost 2 months of ivestgation they suggested us to Change the Audit log mode from FULL to ABBREVIATED that would increase the performance. Kindly check from your end if your TRIM audit log event processing is set to FULL, change it to ABBREVIATED with your business approval, since the FULL would hit more queries on the Database, that will slow down the processing of events. After the changing to ABBREVIATED I am sure performance will be gradually increased.


    Do also post if any other suggestions if you have already looked into in resolving the issue.





    Vinayak (NOT HP EMPLOYEE)