I dont understand what OpenFire work

[Worky]

Good Day! Ihave server:
Debian 11
Openfire 4.7.3
mysql Ver 14.14 Distrib 5.7.42
max 500users
16xIntel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz
64GB RAM - 32GB for Mysql, 24GB for OPenfire (openfire get 17GB of swap)

But I have the saw on graph online session: openfire cant connect all 500 users in one time.
Why??? What it need??

[Worky]

openfire admin console_ database query statistics.pdf (123,6 КБ)
openfire admin console_ system properties.pdf (1,4 МБ)

[Worky]

[Worky]

[Worky]

[guus]

Openfire should be able to handle 500 concurrent connections easily. Sadly, all of this data does not show the reason for any problems.

Can you investigate the Openfire log files?

[Worky]

graph of cpu

pls wait for log

[Worky]

openfire.log.gz (2,8 МБ)

[Worky]

limits for openfire

[Worky]

[guus]

Uff - the logs are full of errors, but I’m not sure if any of these cause the problem. All of these errors might hide the actual problem. It would be a good thing to resolve the most apparent errors. This might help expose the actual problem.

Two problems stand out immediately:

1. Groups are defined in Openfire. Some of these groups contain users that do not exist (maybe the users got deleted at some point in time). Please remove all non-existing users from the group definitions.
2. Software clients that connect to the server send invalid data. Specifically, they seem to send presence stanzas that have a type named ‘groupchat’. That is not a valid type.

[Worky]

1. We get groups and users from LDAP server via php script. Error in DB of LDAP made error in Opefire.
   How critical are these errors that users disconnect over time?

2. I use Pidgin. It still in connect and all nothing.If the problem is in the client, then why doesn’t Pidgin connect?

[guus]

I do not think that any of these issues are critical, but they generate so much noise that it becomes hard to see what the actual issue is. That is why I suggest that you fix them.

Pidgin’s XMPP support is pretty bad, especially in older versions of Pidgin. If you can, consider using a different client. A lot of clients are listed on XMPP | XMPP Software

[Worky]

Hehe. I can cut the errors of userg\group from the log file. Then it will be easier for you to watch it?

[guus]

The logs rotate over time and size. Parsing the log file will help, but when there is lots of data in it, it might have rotated out the imporant bits.

Instead of having to spend time on cleaning up log files, you can better spend that time in fixing the problem. Removing non-existing users from groups is a good place to start.

[Worky]

I did cut errors of users\group from all logs file. Result:
rez.log.gz (1,5 МБ)

Maybe this will help

And this is what happened: after the last launch of the service, a few hours later, the service connected all users and everything is still working.
Overall: the service cannot connect all users at once, but connects everyone later.
What is happening inside the service at this time is unknown.

[guus]

Hmm, are the clients connecting using websockets?

It appears that stanzas are being processed for a session that does not exist - which should be impossible. I believe that we’ve fixed an issue related to this (in context of websockets) in a recent release.

Do you have the same problem if you use Openfire 4.7.5?

[Worky]

                      server                          users

tcp6 0 0 10.75.10.30:5222 10.18.38.6:52400 ESTABLISHED 13343/java
tcp6 0 0 10.75.10.30:5222 10.18.44.63:50694 ESTABLISHED 13343/java
and more…
No apache…
I not use Openfire 4.7.5…

[guus]

I suggest that you upgrade to Openfire 4.7.5 and see if that helps.

[Worky]

I have question: is it normal on screen? has every tread of openfire own connection with DB?