Question
amazon.com
US
Last activity: 21 Apr 2017 8:10 EDT
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***
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Hi Nathan,
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?
Thanks.
amazon.com
US
We are using Jboss Admin Console and our RAM usage does fluctuate with the GC.
Our JVM arguments were recommended by Pega:
java
-D[Standalone]
-server
-XX:+UseCompressedOops
-Xms16384m
-Xmx16384m
-XX:PermSize=1024m
-XX:MaxPermSize=2048m
-XX:NewSize=2048m
-XX:MaxNewSize=2048m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseCompressedOops
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=80
-XX:TargetSurvivorRatio=90
-XX:+PrintGCDetails
-verbose:gc
-Djava.net.preferIPv4Stack=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-Djava.awt.headless=true
-Djavax.net.ssl.trustStore=xxx
-Djavax.net.ssl.trustStorePassword=xxx
-Djboss.modules.policy-permissions=true
-Dpega.logs.dir=/jboss/jboss-eap-6.3/standalone/log
-Dpegarules.config=/jboss/jboss-eap-6.3/standalone/configuration/pegaconfig/prconfig.xml
-Dpegarules.logging.configuration=/jboss/jboss-eap-6.3/standalone/configuration/pegaconfig/prlogging.xml
-Djboss.bind.address= Proprietary information hidden
-Djboss.bind.address.management= Proprietary information hidden
-Dorg.jboss.boot.log.file=/jboss/jboss-eap-6.3/standalone/log/server.log
-Dlogging.configuration=file:/jboss/jboss-eap-6.3/standalone/configuration/logging.properties
-jar /jboss/jboss-eap-6.3/jboss-modules.jar
We are using Jboss Admin Console and our RAM usage does fluctuate with the GC.
Our JVM arguments were recommended by Pega:
java
-D[Standalone]
-server
-XX:+UseCompressedOops
-Xms16384m
-Xmx16384m
-XX:PermSize=1024m
-XX:MaxPermSize=2048m
-XX:NewSize=2048m
-XX:MaxNewSize=2048m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseCompressedOops
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=80
-XX:TargetSurvivorRatio=90
-XX:+PrintGCDetails
-verbose:gc
-Djava.net.preferIPv4Stack=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-Djava.awt.headless=true
-Djavax.net.ssl.trustStore=xxx
-Djavax.net.ssl.trustStorePassword=xxx
-Djboss.modules.policy-permissions=true
-Dpega.logs.dir=/jboss/jboss-eap-6.3/standalone/log
-Dpegarules.config=/jboss/jboss-eap-6.3/standalone/configuration/pegaconfig/prconfig.xml
-Dpegarules.logging.configuration=/jboss/jboss-eap-6.3/standalone/configuration/pegaconfig/prlogging.xml
-Djboss.bind.address= Proprietary information hidden
-Djboss.bind.address.management= Proprietary information hidden
-Dorg.jboss.boot.log.file=/jboss/jboss-eap-6.3/standalone/log/server.log
-Dlogging.configuration=file:/jboss/jboss-eap-6.3/standalone/configuration/logging.properties
-jar /jboss/jboss-eap-6.3/jboss-modules.jar
-mp /jboss/jboss-eap-6.3/modules
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
-Djboss.home.dir=/jboss/jboss-eap-6.3/
-Djboss.server.base.dir=/jboss/jboss-eap-6.3/standalone
--read-only-server-config=standalone-full.xml
amazon.com
US
If we use the SMA to analyze memory instead of using Jboss Admin Console is there a way to tell what percentage of total ram is used by different types of rule cache?
Pegasystems Inc.
US
Nathan,
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.
PropertyReferencePool Report
Limit Current Requests Reused NotFound Pruned
300000 8478 12455817 12447339 8478 0
Estimated size: 1M bytes
amazon.com
US
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.
Updated: 25 Sep 2015 12:51 EDT
Pegasystems Inc.
US
Tracking: SR-A8775
Related:
https://pdn.pega.com/performance/understanding-the-pega0016-alert-cache-reduced-to-target-size
https://pdn.pega.com/performance/understanding-the-pega0017-alert-cache-exceeds-limit
(NOTE: Platform Cache and Alert Optimizations)
https://pdn.pega.com/forums/configuration-settings-reference/configuration-settings-reference-guide
(NOTE: Currently no Pega7 Config Setting Reference Guide)