Openfire 3.81 - Java Memory

How would I go about increasing the java memory? I read a few articles out there but they refer to Linux or running Openfire as an application and not a service:

I have Openfire 3.81 running on Windows 2008 R2 Server, using Openfire service

I already have this setting in place:

xmpp.pep.enabled

false

Would like to increase from the 256mb to 512mb.

Exact steps would be so helpful

Thanks for your time!

I don’t have the exact sets as I am not using windows, but there should be a file somewhere in the installation that actually launches the application (whether as a service or not) and it should have a line similar to this:

OPENFIRE_OPTS="-Xms2048m -Xmx2048m"

(In this example I am giving Openfire 2G of memory) You may only need the -Xmx parameter but my other Java Applications work better with both -Xmx and -Xms

-Xms is the starting memory allocated

-Xmx is the max memory allocated

1 Like

Setting the pep property to false is no longer needed as that leak has been plugged as of 3.8.

My settings for 3000 concurrent used with 1000 active Kraken users on CentOS, VM Ware, <10 % CPU usage, 4 GB memory.

OPENFIRE_OPTS=" -Djava.net.preferIPv4Stack=true -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Xmx2048m -XX:MaxPermSize=192m -XX:NewSize=200m -XX:SurvivorRatio=4 -Xss128k -XX:ThreadStackSize=128 -Dhttps.proxyHost=proxy-europe.my.company -Dhttps.proxyPort=8080 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1199 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

#Thread Stack Size reduced from default (512k) to 128k because Openfire is heavy on thread generation, but threads do not need default of 512k

#Set MaxPermSize to 192m since AppDynamics reports more than 80% usage of PS Perm Gen (marked red) for default at 64m

#Garbage collector settings are recommended by Oracle at http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

#-XX:+UseConcMarkSweepGC for “response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately one second…”

#-XX:+CMSIncrementalMode has to be added to -XX:+UseConcMarkSweepGC to switch incremental mode GC.

#-XX:NewSize=200m -XX:SurvivorRatio=4 to enhance eden and survivor space to 100m and 20m instead of 25m/3m

#Next lines needed to use VisualVM by Oracle to take a look inside of the JVM during operation.

#-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1199 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

**For Windows, please review the installation guide **http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/install- guide.html:

Quote:

"Custom Parameters

Advanced users may wish to pass in parameters to the Java virtual machine (VM) to customize the runtime environment of Openfire. You can do this by creating openfire.vmoptions files in the bin/ directory of your Openfire installation. For the Windows service, you’d create a new text file called openfire-service.vmoptions. Each parameter to the VM should be on a new line of the file. For example, to set the minimum heap size to 512 MB and max VM heap size to 1024 MB, you’d use:

-Xms512m-Xmx1024m

To create parameters for the normal launcher, create a file called openfired.vmoptions (since the openfire.exe launcher invokes the openfired.exe executable to actually start the server)."

1 Like

Thanks everyone! I’ll work on it after-hours.

So for everyones reference this is what I did to get it working.

a) Created openfire-service.vmoptions file in C:\Program Files (x86)\Openfire\bin

b) Inside that new file I put the following:

-Xms512m

-Xmx1024m

c) Restarted Openfire service.

I now have plenty of Java Memory. Thanks everyone!

Hey Walter, you wouldn’t happen to have any Tomcat JVM optimizations for webcat lying around would ya

Not in the moment. We are closing in to get some “internal contract” to work on Fastpath. I am sure you like to hear that. I am sure we will look into the Tomcat VM at that time. In the moment my best guess about Fastpath problems is the code quality…

I am by no means a Java tuning guru. What helped a lot was using VisualVM and read through the Oracle document referenced above.