Dramatic CPU Spiking

James, do you have the ability to look at you database? I have a theory about the memory usage problems and I would like some help.

Can you find out how many rows you have in the ofPubsubItem table, and whether they have payload associated with them?

Thanks.

I just added the xmpp.pep.enabled = False setting this morning so we’ll see if that makes any difference with regards to the memory. Thanks.

I do have full access to this server and the embedded openfire.script database, but I do not know how to access the database file. From the documentation I could find, it looks like the database is HSQL? I don’t have that installed anywhere on this server so I’m not sure how to browse the contents of the file to look at the ofPubsubItem table. If you can provide any instructions on how to do this on a Windows system, I will gladly take a look for you.

Thanks.

First you have to shut down the server, since it is an embedded db.

In your Openfire install, there is a /bin/extra directory with an batch file called embedded-db-viewer.bat. You can run this and it will provide a simple UI to access the database.

I don’t know how much sql you know, but type select count(*) from ofpubsubitem in the upper right pane and press **Execute SQL **This will tell you how many rows you have.

You will have to make a small change first though, I noticed that some of the jar files in the /lib directory are packed, and will need to be unpacked before you can run the tool. This will require a JDK so you can use the unpack200 tool.

You can also make a copy of the file while openfire is running, open the copy and count the number of ofpubsubitem lines. How small/big are the embedded-db/openfire.* files?

It’s been 11 1/2 days since I did the “xmpp.pep.enabled = False” setting on my Jabber server and the Java Memory has remained stable as has the Openfire service. I have not done the DB query requested above yet only because the system has stayed running well to this point. If I have another instance where the service goes to 100% CPU and hangs there, I will check out the DB and supply the requested information.

Thanks for all the help.

James

Hi James,

Did you simply add: “xmpp.pep.enabled = False” to the system properties page in the admin console and than restart the service? Trying to understand specifically where to add this variable.

Yes, that’s exactly what I did.

You just scroll to the bottom and add “xmpp.pep.enabled” to the Property Name field and “false” to the Property Value field, then hit Save Property.Then restart the server.

Okay. This is what I did. Thanks guys.

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).