KBEC-00361 - 32-bit vs 64-bit JVM Memory usage

Article ID:360033189711
2 minute readKnowledge base


Any operation in the CloudBees CD (CloudBees Flow) server (UI or command line), seems to throw a LazyInitializationException like this

InternalError: org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: …​ followed by a stack trace for action attempted


Files to consider



  1. Check the available memory in the Host.

  2. Check the following lines in wrapper.conf that indicate memory allocation:

# Initial Java Heap Size (in %) wrapper.java.initmemory.percent=50 # Initial Java Heap Size (in mb) #wrapper.java.initmemory=2048 # Maximum Java Heap Size (in %) wrapper.java.maxmemory.percent=50 # Maximum Java Heap Size (in mb) #wrapper.java.maxmemory=4096

  1. Check if the allocated amount of memory matches the values reported in commander.log

-→ commander.log contains snippets of memory usage every 15 minutes in this format

G1 Old Gen usage 293.92 MB 1.724 GB 1.895 GB 2.000 GB G1 Old Gen collection 0 B 0 B 1.895 GB 2.000 GB G1 Old Gen peak 293.92 MB 1.895 GB 1.895 GB 2.000 GB

-→ Make sure G1 Old Gen Max setting matches the % value set in wrapper.conf


If you notice that Max value does not increase about 2.0 GB, then its because the JVM being used is 32-bit.

Run "uname -a" to get details about the OS itself. If the JVM is 32-bit, the swap space cannot be configured for more than 2GB.

A PAE kernel allows Linux to see all the RAM, but it does not change the fact that each individual process is a 32-bit process, and thus can only run the 32-bit JVM. A 32-bit JVM is constrained to a maximum of 2GB of heap space; there is no way to get around that so the only solution if you need more heap for a single process is to upgrade to a full 64-bit OS that can support the 64-bit JVM.