Anormal memory usage in Production
Hi,
We have an application on PEGA 7.1.9 (CSHC 7.1.4).
In production, the memory usage keep growing and never go down, even after the end of the day when users log out. (as you can on the attached picture)
Have you any suggestion about what to check to identify the root cause of that issue ?
Thanks.
Accepted Solution
Pegasystems Inc.
US
HI @ShezadM8,
After speaking to my teams here, it was discovered that it would be best for you to re-open your Support Request so that they can best assist you.
Thank you,
Pegasystems Inc.
IN
Hi,
For starter can you check if GC is happening or not?
Check the Pega-Alert logs for PEGA0028 alerts
https://docs-previous.pega.com/performance/pega0028-alert-gc-cannot-reclaim-memory-memory-pools
Thank You
Oligos
FR
Hi,
It seems GC is not happening. I don't have any of theses alerts.
I'll try to find how to configure GC, setenv.sh, or prconfig.xml or somewhere else. I'm kind of confused.
Thanks
OCBC Bank
SG
Hi,
If you are finding PEGA0028 alerts, it means GC is unable to reclaim memory. If you are seeing this alerts too frequently, it could represent your heap is not sufficient and you should consider increasing heap.
If heap is continuously growing and even if there is not much users logged in, try taking multiple heap dumps and analyze for the memory leaks.
Thanks,
Sandeep.
Pegasystems Inc.
IN
Hello @ShezadM8 ,
Thanks for the update. Please share the SR# with us so that we can continue to track it through this post.
Regards,
Cognizant
IN
In PRPC7.1.9 WE have known memory leaks for rule assemble cache, direct stream encoder class. so please deploy corresponding hot fixes in the system.
Apart from that please turn off DNode Listener ,FTSIncremental indexer agent which will bump the volume in SLA and consume more system resources.
Regards,
Chandrasekhar Bhagath ,Vasireddy
Allianz Germany
DE
The graph you have attaced indicates most likely a memory leak. This is because despite major GC (some over 40 sec) you total heap size is still increasing. So to move further, you need to dump the heap analyze it and see where the leak is coming from. Most of the time it is from Pega Cache (MRU - property reference cache). But first you need to do heap analysis and check alerts like Pega0028. Check if there are other alerts Pega 0005 or Pega 0042 and could co-relate with Pega0028.
Also make sure the major GC does not exceed over 5 -10 sec,
Oligos
FR
Hi,
After providing elements as requested on the SR, the conclusion was that everything is normal.
Our systems reboot on a daily basis, so in order to see if PEGA's conclusion is true, we didn't restart the system on monday night. So after viewing the memory old gen usage and the garbage time on this 2 days period, we're not sure that PEGA's conclusion was true.
You can see the graph attached. It seems that there is an issue.
Accepted Solution
Pegasystems Inc.
US
HI @ShezadM8,
After speaking to my teams here, it was discovered that it would be best for you to re-open your Support Request so that they can best assist you.
Thank you,