There is no single right number - the JVM settings depend on the load - but these are the IBM baseline recommendations and the tuning path for traditional BPM / BAW cluster members:
- Heap: 64-bit JVM, initial = maximum to avoid resizing, 4-8 GB for a typical Process Server member (-Xms4096m -Xmx4096m), up to 8-12 GB for heavy coach / document loads; above that GC pauses hurt - add members instead. Process Center: 4 GB is usually enough; the deployment manager 1-2 GB; node agents 512 MB.
- GC policy (IBM J9): -Xgcpolicy:gencon (default) with a nursery sized for the churn of coach requests - roughly 25% of the heap (-Xmn1024m for a 4 GB heap); -Xcompressedrefs is default on 64-bit; enable -verbose:gc in production - it is cheap and the only way to size properly.
- Threads: WebContainer thread pool 50-100 per member (coach requests), the BPM event manager thread pool (100Custom.xml <event-manager><thread-pool>) 10-30 depending on UCA / timer load, JDBC connection pools sized to (WebContainer + EM + other) threads per member and kept under the database's connection limit across members.
- Other JVM arguments: -Xdisableexplicitgc, -Xshareclasses (faster start), -Dcom.ibm.jsse2.overrideDefaultTLS=true on Java 8 (TLS 1.2 by default for outbound calls), the heap dump on OutOfMemoryError is on by default - add -Xdump:directory=/var/dumps so that dumps land on a big disk.
- OS: ulimit -n 65536, enough swap disabled or small, transparent huge pages off on RHEL for J9.
# admin console: Servers > Application servers > <member> > Java and Process Management > Process definition > JVM
Initial heap size: 4096 Maximum heap size: 4096
Generic JVM arguments: -Xgcpolicy:gencon -Xmn1024m -Xdisableexplicitgc -Xshareclasses:name=baw -verbose:gc -Xverbosegclog:/var/log/baw/gc_%pid.log -Dcom.ibm.jsse2.overrideDefaultTLS=true
Method: start with the baseline, run a load test with realistic coaches, read the verbose GC log with the IBM GC and Memory Visualizer (GCMV): target < 5% time in GC and no long pauses; if the tenured heap keeps growing, look for leaks (large execution contexts, caches) before adding memory. On CP4BA the same numbers go into the pod's resources and jvm_customize_options (heap ≤ 75% of the memory limit).
References