Posted: 2 Jun 2016 8:11 EDT Last activity: 3 Jun 2016 16:32 EDT
Rule Assembly Alerts (PEGA0037)
I am at a customer site and the application is already in production.
We are consistently receiving PEGA0037 alerts. About 600 per day, The number is quite high since there are no rule changes in Production.
Moreover some of these alerts are taking up to 50 sec.
I have attached a snapshot of the Rule Cache Management for review.
Please let me know your thoughts/comments that would address the Issue.
Also below is a comment received from Gabe
"EGA0037 indicates a slow rule assembly. I don't believe it is related to the PropertyReference cache at all.
PEGA0037 is most commonly caused by a slow database (in which case you might also be seeing PEGA0005) and/or by a flood of assemblies. So you'd look at PAL to see what's happening, evaluate whether we need to use static assembly or some other way of avoiding or preloading those assemblies."
Did anyone tried static assembly and had any success ?
Just a sanity-check - can you confirm that your 'PegaTemp' directory isn't being deleted via a script (etc) - this on-disk cache should normally stay pretty static once it is built ; but building it from scratch will cause Rule Assembly to take place; which would increase the likelyhood of PEGA0037 alerts.
Are you able to monitor the PegaTemp directory over time ?
Also: I checked the SR-A71566 and I see you have attached the following files:
The XLSX files show that the system is generating a lot of PEGA0037s as you say: but could I ask you also to provide the original 'raw' ALERT files to the SR - as we can then process this with standard tools (such as PLA) more easily.
(I believe the XLXs file were generated by extracting data directly from the DB - which is fine - but it might a bit easier to analyse them in the logfile format).
Thanks for this: can you confirm that Alert file covers the right time period ?
There are only 5 PEGA0037 alerts in this and the maximum kpi is just over one second ?
It is possible that the system has 'settled down' now ? (Maybe the PegaTemp was cleared and now it is (almost) fully rebuilt ?)
Or are you expecting that there should be *zero* Assembly going on here ? (so one PEGA0037 is too many ?) : gennerally you should get no Rule Assembly on a Production system : except following a new Rule Import and that kind of thing (or, if the PegaTemp is cleared).
Ok : but please attach the logs to the SR that you already : SR-A71566, rather than emailing me directly.
So the XLS files you attached are dated 10th May and 13th of May.
The 'raw' log file covers part of the 26th of May*.
Is the system currently showing lots of PEGA0037s - or was it just occuring on between the 10th,13th and then settling down by ~the 26th ?
Can you also ZIP up your current PegaTemp directory and attach that to the SR ? We should sanity-check the timestamps of the files in the PegaTemp : so we can see whether there is any possibilty that the PegaTemp directory got cleared (which would cause Re-Assembly to occur: increasing the frequency of PEGA0037s) and then subsequently got rebuilt with system-use (which would gradually decrease the frequency of PEGA0037s).