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
  • What version of database are you using? Oracle? SQL?

    Any reason why you upgraded to 7.2.1 3 months ago when that version is a few years old? Why not 7.3.5 or 8.x?

     

    Event processing has had issues in older versions, but you should be able to get it processing ok.

     

     

  • Hi Grundy,

     

    Thank you so much for your response. We are using SQL 2008 SP3 (10.0.5500.0). 

     

    The reason of upgrading to that version was after getting consultancy from HP and the landscape that we have here is complicated and super large.

     

    The issue right now after some tweaking is that the word processing is working fine but the schedule event triggering and audit log is always stuck in 1000.

     

    Attached will be some info.

     

    Appreciate for your thought.

  • This almost looks to me like the events weren't processed/purged prior to the upgrade?

    Or did you really generate 60 million events in the last 3 months?

  • 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?

     

     

Reply
  • 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?

     

     

Children
No Data