This is how it looks for me:
I think Iāve solved my problem. I dropped the data from the ofPubsubSubscription table, and after a server reboot, everything returned to normal. Java stopped hogging memory, and CPU load returned to normal. Iām continuing to monitor the situation. I hope Iāve finally solved my problem.
Has the truncated table remained empty or are entries again populating? Openfire admins would want to be careful not to arbitrarily delete this table as users may be using it!
1 Like
Update:
My Clean install has been running for 2 days now. I have all of the same plugins, groups and group chatrooms configured. I have my SSL Cert installed and all of that. Sitting at a cool 16.8% of 512MB Java Memory. Right where itās been since initial startup(Ā±2%). Itās running like a champ.
Iād like to second this. Deleting stuff from the database arbitrarily is risky.
Also, I still would like to know if:
- Openfire 5.1.0 causes redundant, duplicate database rows to be added, or
- if the redundant database rows already pre-existed, but cause a problem in Openfire 5.1.0 (maybe because it is more effective in loading things from the database, which is an improvement that we added to 5.1.0
Lastly, we did eliminate a potential source of such duplicated database rows in 5.1.0, but I have no idea of thatās the exact source that generated the rows that are giving us problems. Iām eager to find out when the duplicate rows are being added, and if that is still happening in 5.1.0.
Iāve received a database dump that was taken before the upgrade to 5.1.0. That dump showed an enormous amount of rows in the ofPubsubSubscription table.
This seems to suggest that the root cause for this problem predates the 5.1.0. (Iām even wondering if the root cause has already been fixed in 5.1.0 with OF-3197).
My suspicion is that people are experiencing issues with 5.1.0 not because it necessarily introduces a bug, but because it is doing a better job loading pubsub-related data from the database in memory (because of the improvements introduced by OF-3196 maybe). The issue is caused by there being way to much data in the database.
Update: it turns out that the database dump that I looked at was created after the upgrade to 5.1.0. That means it sadly doesnāt rule out 5.1.0 being a source of this issue at all.
I have created a new ticket in our bugtracker for this issue: OF-3306
No, this table remains empty. The server is running stably, the load on the processor and RAM is minimal.
Thank you for helping me solve my problem!
1 Like
Just as a data point.
I have database dumps both before and after the 5.1.0 update and the bloat was definitely there long before the update.
1 Like
Oh, that is very useful information, thank you. Do you enough information to conclude that since 5.1.0 the bloat has stopped increasing?
The database dumps started to grow when we went from 4.7.5 to 5.0.2 at the end of November 2025. In 3 weeks the size doubled.
We installed 5.0.3 in late December and at the end of March the database dump went from 200MB to 2.2GB and by May 18 it was at 4.2GB. Since it is running as a VM, it was possible to keep it āfunctionalā by throwing more resources at it.
After installation of 5.1.0 the database size did not grow anymore, but now the behaviour of Openfire had changed and memory usage shot through the roof, had to give 16GB to Openfire and 4GB to MariadDB. I eventually wiped the ofPubsubSubscription table and removed all rows in ofPubsubAffiliation where affiliation=ānoneā.
It now runs happily with 1GB for Openfire and 2GB for MariaDB and it looks like those numbers could be decreased even more.
1 Like
Hello.
I was facing the same or similar problem.
Simple instalaton on Windows and SQL Server and users from AD.I was running the 5.0.5 version then upgrade to 5.1.0, no problem during upgrade. After completing upgrade the service starts, all of a sudden cpu and memory spikes. On openfireās server page I could see the Java memory on 100% too.
After reading the posts here, with the service stoped, I backed up the DB and then delete all rows from ofPubsubSubscription table. Started the service and problem solved.
Thank you.
Again, I cannot stress enough that deleting all rows from that table is a bad idea: although most data is redundant, not all data should be deleted.
We are working on an implementation that will allow an administrator to remove only the redundant data.
I understand the logic behind that concern and I apologize for propagating the idea of deleting database content without a big caution, āDanger, Will Robinson!ā. 
A fix for this problem is now available in our nightly builds of Openfire (starting with the one from June 18āth). The fix has several aspects:
- it should further guard against additional bloat (redundant pubsub subscription records) being introduced (although there are indications that this was already stopped by other changes that went into Openfire 5.1.0)
- it reduces the memory footprint of each of the records (reducing the chances of having memory issues when they are all loaded into memory)
- it stops loading redundant records from the database (not loading all the bloat should significantly reduce resource usage
- a new maintenance task is introduced, which allows an administrator to perform a one-shot action, to clean up all redundant records from the database. This looks a bit like this:
Although weāve tested these fixes in a number of environments, it would be very helpful to get feedback from people in this thread - especially those who have experienced the issue first-hand.
Hi @guus,
Early testing appears the fix(es) have worked!
We installed nightly from 2026-06-22 and ran the cleanup link. It cleared more than 8.5 million redundant rows from our database, leaving around 8000 rows.
Java memory is <100MB.
The only odd thing is Pade plugin is crashing. I am not concerned nor have at the logs. Itās not a plugin we have ever used much and it appears it is no longer maintained (?), so itās ok if that one stops working.
Thank you for the fix!
-Joel
1 Like