Good Day! Ihave server:
mysql Ver 14.14 Distrib 5.7.42
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??
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?
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:
- 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.
- 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.
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
Hehe. I can cut the errors of userg\group from the log file. Then it will be easier for you to watch it?
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.
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.
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?
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
I not use Openfire 4.7.5…
I suggest that you upgrade to Openfire 4.7.5 and see if that helps.
I have question: is it normal on screen? has every tread of openfire own connection with DB?