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

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.

We haven't been able to identify the cause, so we have open a SR.

Hope we can find something that way.

Thanks.

The SR created for this issue is SR-C28021: Memory Usage

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

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,

We'll look on these and i'll also update the SR in order to know what Pega recommand.

Thank you everyone for your answers.

Hi,

This topic can be closed.

As told in the SR closed, we'll make more tests and see if a new SR is needed.

Thx to everyone.