powered by Jive Software

CPU was at or near 100% (90+% was the openfire-service.exe)

We have been using Wildfire/Openfire with SPARK as the clients. We were on using 3.6.3 and we started facing problem of high CPU. CPU was at or near 100% (90+% was the openfire-service.exe). We tried by upgrading it 3.6.4 , for few days it worked but again we started facing the same high CPU utilization problem. During this time new users are not allowed to login but there is no problem for the users who has already logged in. We need to restarts the service

We have installed it on the Windows 2003 Server VMWare image with 3 Gb RAM and VMOPTIONS configured.

IS there any way to avoid this high CPU utilization ?


It is likely that your CPU problem is actually a memory related issue: if the JVM memory is (almost) exhausted, Java is going to try harder and harder to free up memory, which will cause your CPU usage to peek.

There’s a couple of things you can do. I would start with verifying if this is indeed a memory-related issue. You can do this by monitoring the JVM proces that is running Openfire. There’s a lot of ways of doing this, but a very fast and easy way to do this is by using the Java-monitor plugin, as described in New Openfire monitoring plugin

If you feel lucky, you can eliminate an issue that’s popping up a lot lately. The PEP routines in Openfire can suffer from a memory leak (especially if one or more of your users are using the Empathy client). As a workaround, you can disable PEP, by setting the Openfire property xmpp.pep.enabled to false. More information can be found in this discussion: Re: Openfire 3.6.4 memory leakOpenfire 3.6.4 memory leak with Empathy

Thx for the reply…but this is my production server so I do not think my security team will allow me to get the server monitored from outside…is there any other way to monitor it in house and to check if it’s related to JVM ?


Definately. All JMX based solutions will work - basically, you can use the same things that you can use for any JVM. Read up on JConsole, for example. There are more elaborate tools (that will present the data somewhat more polished) available too - Check with any of the inhouse developers / administrators what they prefer.


you may want to read http://www.igniterealtime.org/community/docs/DOC-1033 and https://visualvm.dev.java.net/jmx_connections.html to enable remote profiling, while remote means form the same or another computer which has access to a specific port on your server.

Or start Openfire with “-XX:+PrintGCDetails -Xloggc:c:/path-to-openfire/logs/gc.log” to log the GC statistices.



I have reinstalled the server again. But again after few days I am started facing the problem . i have tried by

The property xmpp.pep.enabled should be set to: false

but still no luck. Can you please suggest some solution for this. Its due to memory leakage only.

Also tried the,

We corrected the issue in the meantime by adding the property cache.username2roster.maxLifetime and setting it to 419430400 which 20 minutes (rather than its default 6 hours). For anyone interested, who may be having a similar issue now, this property can be added through the admin interface - no programming required.

But this also didn’t work for me.

Any other suggestion



Have you been able to put in place any of the monitoring tools that we previously discussed? That can help in determining what’s actually wrong with the server, and should lead to better results than simply switching off functionality in the hope that the problem goes away.


Thanks for the reply…

No . I was not able to do that last time. This time will try to install the tool and check .

Meanwhile is there any other way to control the memory leakage ?