Dramatic CPU Spiking

I’ve experienced problems since enabling the xmpp.pep.enabled switch. In my case randomly the users contact list will stop showing for users who log on. If you are already logged on, all users are visible in your contact list and the client functions normally. If you logout and back in again, no users will show in the contact list. We are forced to restart the openfire service. I am not sure at what point this starts or what might trigger it since 85% of our users stay logged in. We will simply get a report from a user who had restarted their computer (or closed the client), that they have no contacts showing. Logging off the client and back on for a user who otherwise could see all contacts will reproduce the issue. At this point we are forced to restart the service.

This only started happening after adding and enabling the above switch.

Any ideas? For now I have removed the switch and gone back to a scheduled task of restarting the service every Sunday at 0300.

What does the PEP service do? What do you lose by disabling it? I have disabled and so far see no issues, due to having the process spiking / memory leak issue with 3.7.1.

At least one person has indicated the PEP service is causing issues with the contact list not updating. Any other reason not to disable PEP?

I have no idea what it does, but I haven’t had any complaints from users since disabling it.

Robin says here it stands for virtual pubsub service http://community.igniterealtime.org/message/219707#219707 It is safe to disable it if you only use simple messaging.

I am pretty sure you are the first to see this particular problem when switching off PEP. I can’t think of how turning off PEP could have that affect.

On another note, if you are in a position to do so, I believe the latest nightly build actually fixes the memory problem. We could use some brave souls to try it out if they are operating in environments that will allow it.

That is, where it is OK to use an unreleased, unofficial build.

I fiddled for 20 minutes trying to figure out how to download the nightly build. When I click around on that link, I see the nightly build lists but there is no download button to actually get the build. If I try to create an account on the bamboo server I get an internal error / crash page from the web server.

How can we get the nightly build?

You have to select the latest build number for the build you want.

For example, for Nightly Windows Build it shows **#611 **as the latest. Select that build, then the Artifacts tab. You will see a link for

Project Windows distribution files

Select this link and you will see the actual artifacts to download.

Thanks, that got the download going for me.

After upgrade my Openfire still won’t start, I think due to a huge (and possibly corrupt) database. Honestly, since we use LDAP for auth I don’t understand why the database is ‘allowed’ to get so big. I don’t need chats stored more than a week or so. My openfire.script file is over 500MB at this point.

Is it possible to blow away my existing database without losing my configuration, and prevent this large database growth from happening again?

thanks… (i’m using the embedded database, FYI. about 400 users).

If you shutdown Openfire you can manually edit the ‘database’ and delete all the archives out of it (Wipe out all the INSERT INTO OFMESSAGEARCHIVE lines). You can also disable conversation logging through the ‘archiving - > archiving settings’ menu option.

If you want to purge logs after a certain amount of time, you’re better of moving to a real database (even if it’s just MySQL) and having a cronjob run SQL to delete rows out of the table. The embedded database isn’t much use for a production Openfire installation. You could perhaps just grab your system properties out of the embedded database and manually insert them into whatever database you move to to avoid reconfiguration.

Hi,

take a look at the graphs attached.

If you set -Xmx (maximum heap space) and the application reach that maximum Heap Space, the garbage collector will run forever and CPU usage will rise significantly.

Withou that argument, java will keep increasing heap space until it occupies all memory, fisical and swap.

Openfire, up to version 3.7.1 has a memory leak related to PEP (see other responses).