Increasing the Java Heap size for vRealize Orchestrator Client (7.x)
Sam McGeown
Back in January 2015 I wrote an article on how to modify the Java heap settings for the vCenter Orchestrator client when working with very large workflows. Since vRealize Orchestrator 7.x has been released, we no longer have an installable client, just a Java WebStart file (.jnlp) that you run, or a package that you can download - but nothing that installs.
Note that none of this is official or supported by VMware as far as I know - it’s the results of my experimentation which has shown some performance improvement by increasing the configured memory pool. Use it at your own risk!
Modifying the Java WebStart application .jnlp
A Java WebStart file is basically just an XML specification that tells Java WebStart how to run the app - all of the components are downloaded at run time. However, because it’s an XML file, it’s dead easy to read the configuration, and sure enough, there’s a configured memory pool setting:
I modified it to “-Xmx1024m” and restarted the client - and sure enough, the memory usage increased:
Before the config change, 512Mb RAM is in use
After the config change, 1GB of RAM is used
Modifying the vRO Workflow Designer application
So, what about the downloadable applications? Well, on MacOS the application is easy to explore, just download and unzip the application, then right click and “Show Package Contents”
Within the package is “Info.plist”, which is the equivalent of the XML jnlp file, and sure enough there are some JVMOptions specified, one of which is the memory pool, which is already set to 1GB “-Xmx1024m”
Even with my old giant workflow, it’s not easy to push the client over 1GB RAM, but for the sake of experimentation I edited the Xmx to be “-Xmx2048m”, saved the file and gave it a go, and sure enough it can now consume more than the original 1GB
Finally, I took a look at the Windows download, which doesn’t have an obvious configuration file as they’re all either .jar or .exe binaries. By default it seems to consume up to 1024MB RAM, but I couldn’t get it over. The vso.log file that is generated when you run the application shows that it looks for “vmo.properties” in the same directory as the application, but I was unable to work out a way of setting the memory pool. I also tried setting the environment variable for Java using _JAVA_OPTIONS=-Xmx2048, but was unable to push the client over 1GB RAM.
So, to summarise:
- For most people, there is absolutely no need to modify the memory used by the vRO client!
- If you want to easily control the Java Memory Pool with vRO, use the .jnlp
- The downloadable executables have a default of 1024Mb, so there’s a benefit to using them (other than they start quicker because they’ve already got the binaries downloaded)
- Configuration of the Windows executable may be possible, I just don’t know the settings for the vmo.properties file.