Question
CTS
AU
Last activity: 15 Jun 2017 0:37 EDT
Seeking Advise on cache tables truncation in order to avoid performance issues
We are advised to truncate the following cache tables to avoid performance issues. Please advise me that how often we can do this cache tables truncation? Can we do this while Pega is online? Do we have to restart after truncation by deleting the PegaRULES_Extract_Marker.txt file? Is this following list is enough or do we have to consider any different cache table(s) for Pega 7.1.9? Would it be feasible to have an Agent activity to truncate these tables by weekly without system restart?
TRUNCATE TABLE PR_SYS_APP_HIERARCHY_FLAT;
TRUNCATE TABLE PR_SYS_APP_RULESET_INDEX;
TRUNCATE TABLE PR_SYS_CLASS_ANCESTORS;
TRUNCATE TABLE PR_ASSEMBLEDCLASSES;
TRUNCATE TABLE PR4_RULE_SYSGEN;
TRUNCATE TABLE PR_SYS_APPCACHE_ENTRY;
TRUNCATE TABLE PR_SYS_APPCACHE_DEP;
TRUNCATE TABLE PR_SYS_APPCACHE_SHORTCUT;
TRUNCATE TABLE PR_SYS_CACHE_DEP;
TRUNCATE TABLE PR_SYS_CACHE_ENTRY;
TRUNCATE TABLE PR_SYS_CACHE_IMPL;
TRUNCATE TABLE PR_SYS_CACHE_DEP;
***Updated by moderator: Lochan to branch reply into a new post***
Original Post: What cache tables should be truncated?
Accepted Solution
OCBC Bank
SG
Hi Anurathan,
Adding point to above inputs. The main advantage of Caching is to reuse already assembled rules rather than querying out tables and assembling every time they are called. This reduces the time to assemble rules or perform same action again and again. This will improve performance.
The cache will be deleted automatically based on the cache limit set in the DSS or prconfig.
Below are the default limits.
fua/global/instancecountlimit - 20000
fua/personal/instancecountlimit - 20000
collections/mru/PropertyReference/instancecountlimit - 10000
collections/mru/LowerCase/instancecountlimit - 10000
collections/mru/UpperCase/instancecountlimit - 15000
There are Pega OOTB agents like PurgeAssemblyDatabaseCache to purge cache based on the time interval.
However, there are some scenarios where cache needs to be cleared manually like new rules added or modified and are not referenced due to cache or scenarios like RuleNotFoundExceptions are appearing in logs even if the rules are present.
Pegasystems Inc.
IN
Hi Anurathan,
Is there any SR associated to this so i can have better understand why this has been advised ?
Points to be noted:
1) If there is a specific issue then only it is advised to clear the cache.
2) You should need to bring down the application server and then perform the cache clearance.
3) You should not schedule an activity for this.
Accepted Solution
OCBC Bank
SG
Hi Anurathan,
Adding point to above inputs. The main advantage of Caching is to reuse already assembled rules rather than querying out tables and assembling every time they are called. This reduces the time to assemble rules or perform same action again and again. This will improve performance.
The cache will be deleted automatically based on the cache limit set in the DSS or prconfig.
Below are the default limits.
fua/global/instancecountlimit - 20000
fua/personal/instancecountlimit - 20000
collections/mru/PropertyReference/instancecountlimit - 10000
collections/mru/LowerCase/instancecountlimit - 10000
collections/mru/UpperCase/instancecountlimit - 15000
There are Pega OOTB agents like PurgeAssemblyDatabaseCache to purge cache based on the time interval.
However, there are some scenarios where cache needs to be cleared manually like new rules added or modified and are not referenced due to cache or scenarios like RuleNotFoundExceptions are appearing in logs even if the rules are present.
CTS
AU
Thank you Sandeep. Very valuable input. Could you please share some Pega 7 reference to find out detail information of the DSSs you have listed here. I couldn't find some of the DSS in the system. Is there any techniqes/mathematics to match the "instancecountlimit"? (Say for example, we have two nodes and 300 active users at any point in time in the active business hours.)
OCBC Bank
SG
Hi Anurathan,
Hope you can find your answers in below links.
https://community.pega.com/sites/default/files/help_v719/procomhelpmain.htm
https://pdn.pega.com/performance/performance-guidance-for-production-systems-system-settings
All are related to Cache Management and Performance.
PEG
US
Deleting caches as a matter of policy is generally a bad idea. (Pega used to suggest it -- we no longer do so.) Besides the performance hit of having to rebuild caches, you can introduce problems that would never have occurred otherwise. Cache truncation should only be done as a last resort to a real problem.
One classic issue I've seen time and again is where, because of cache truncation, Libraries are being rebuilt during system startup. While the rebuild is in progress, some rule fires which requires a Rule-Utility-Function from the incomplete library. The RUF is not found (the Library is not yet available), the assembly of the referencing rule fails, and the referencing rule is now broken and will need to be recompiled by explicit direction (usually the SMA tool). Depending upon what is broken, your whole system may be inoperable.
Cognizant
IN
Hi All,
We also performed truncation of all this tables. After doing so we are facing issues with Rule Creation and Saving.
Any suggestion what could be the issue?