We have an Openfire server that we recently upgraded from 3.6.4 to 3.7.1, that accommodates about 150 users. While we never had any issues prior to the crash, almost immediately after the upgrade we saw that Openfire is crashing almost every day. Basically, the memory usage shoots from practivally nothing all the way up to almost 1GB, and the CPU usage jumps to 99%. This happens at different times of the day, when there really isn’t a change in the number of users logged in or the amount of activity. When this happens, clients connected to the server experience a lot of slowness and we end up having to kill the openfire PID and restart the service.
We have stack traces from kill -3 from each time we’ve had to restart openfire due to crashing (is attached as debug.txt)
When we did the upgrade, we simply did rpm -Uvh and updated the package, which is the same process we used when upgrading to 3.6.4.
Anyone else experience this issues? Any help would be appreciated. debug.txt.zip (4787 Bytes)
We’re experiencing the same thing. However we are using a Windows platform. The error is something along the lines of…“Java memory heap”. I’m not sure on how to increase the memory on the server.
Openfire up to and including version 3.6.4 (and looks like 3.7.0 too) suffers from a memory leak in its PEP component. If your Openfire server is crashing with OutOfMemoryExceptions, you might be having this problem.
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: Openfire 3.6.4 memory leak with Empathy
A stack trace does not really help to lock down OutOfMemory errors. The java command “jmap -histo OPENFIRE-PID” may produce better results, it returns the number of instances. If you run every n minutes it may give one a better hint what’s going wrong.
I saw that message when I logged into the forums, only weird thing is that we’re running 3.7.1, and when we were running 3.6.4 we did not have this problem. However, I went ahead and tried this anyways, hope it works
I want to update this post to 1) thank everyone for their help and 2) disabling xmpp.pep resolved our problem. Since disabling this, we have not had a single crash in two weeks.