RAM and prconfig/collections/mru/propertyreference/instancecountlimit/
We raised our setting from 15000 to 25000 and our RAM usage went up from 26% to 40% of 16GB for about a 2.24GB increase. Is this typical? What is the most amount of rules you can deploy on an installation before you starting hitting hard capability limits of the product?
***Updated by moderator: Lochan to add Categories***
What utility are you using to check your memory usage? The JVM heap usage may have been greater at the time of your observation, but should be reduced after garbage collection. Can you share your JVM arguments?
I am not surprised at all with increase of heap usage after increasing the number of property references. It should not be an issue as long as you have enough heap (not RAM, which is the total memory). Also the heap usage has no direct relationship with the number of rules, rather it depends on many factors, namely, number of requestors, size of each requestors, etc.With 64bit JVM, there should not be any practical limits as long as your machine has enough RAM to run both java (Pega instance) and the associated native processes. The performance tuning is a non-trivial process and Pega consulting has a performance group specializing just that. Contact your account executive if you want to go that route.
The MRU reports should tell you how much memory is used by the property reference pool. Setting property reference pool to 100,000 or 200,000 is common -- I can't see how setting it to 25,000 K would have any impact. Did you set it to 250k?
From system management application, go to Advanced / Reports and click button Factory Reports. Search report for the "PropertyReferencePool Report" (sample below)
In my system the limit is 300K; 8500 or so are currently cached and usage is 1MB.
If you continue seeing high / huge heap, take a heap dump and let's analyze. I did see one data-intensive BRE application that totally blew out and blew up the proeprty reference pool cache and pointed to a design issue, but that was an exceptionally unusual application.
Andy it is comforting to hear that you can raise the limit so High(100k-200k) and not see a big increase in RAM usage. Because this was looking like it was going to be a Big Blocker for us...
I am guessing that the fluctuations we saw can be attributed to normal Garbage Collection activity and that if we attached a memory profiler then we would see the normal saw tooth pattern associated with garbage collection and that we miss-attributed this fluctuation to changes in the prconfig/collections/mru/propertyreference/instancecountlimit as suggested by Richard in the first reply to this post.