The file handle owned by Openfire is still valid. Openfire can write to it as long as there is enough free space in the file system.
Iām having the same problem. We have approximately 75 active sessions at any given time.
Openfire 3.10.0 release running on Ubuntu 14.04.2 in a vSphere 5.5 VM. 2 vCPU & 4 GB RAM
Clients all use Spark 3.7.0
Java 1.7.0_79
We could not make it through a full work day without the CPU spiking to 100%. We have reverted to Openfire 3.9.3.
This isnāt really a problem and from your screenshots and logs you shouldnāt be experiencing much slow down if any. Reading through the thread it looks like everyone is a little confused on what CPU utilization and System Load are.
100% CPU doesnāt mean youāre maxed out, just that the processor is being used to its full potential. System load is how much work is actually being done. From your screenshot of top/htop your system load is averaging 1.2x. If this is a virtual machine add another core and watch the system load. You may also want to increase the available ram to something greater than 480mb. Try a full gig of memory.
We run on a quad core with Asterisk, Apache, and several resource heavy web apps running for 50-75 users. We rarely see system load over 3.
This may help clarify system load vs CPU utilization. Understanding Linux CPU Load - when should you be worried?
This may also help:
Virtual Memory Usage from Java under Linux, too much memory used - Stack Overflow
I tried Philipās set of Java options and that seems to have fixed the problem for me. Previously, I had been disabling IPv6 and setting the Java heap to 1GB, but the CPU would race after a couple days. Java memory utilization was consistently in the high 90ās%. Now, after enabling garbage collection and setting the init/min heap size as above, mem utilization is in the mid 80ās% and our OF3.10.0 server has been running great for over 9 days and just over 47 total minutes of CPU time. Using default JVM 1.7.0_76.
I would disagree with your assessment, at least for some of these and certainly myself.
Having run OpenFire since almost the beginning, going from very low CPU loads to much higher loads, including CPU fans revving way up, people reverting to pervious versions and no longer having issues, something is clearly amiss here with the new version.
Agreed. Iāve been running various versions of OpenFire for 10 years now and never seen this issue until now. Java is taking up 100% of the CPU time which is an unambiguous culprit to me. Besides, when we see this spike, OpenFire becomes unusable.
We canāt all be wrong.
I donāt really care what you call it, there is a problem with the latest release.
Running 3.10.0 with 2 vCPUs and 4GB RAM top indicates 99.5% CPU and users could not send messages or even login. This happened multiple times per day. Reboot and the phones fall silent.
Running 3.9.3 with 1 vCPU and 4GB RAM, top will occasionally show as high as 25% CPU. No calls all day.
Same user load of right around 75.
Iām not sure how you can disagree with how top/htop reports on CPU utilization and System Load. Anyway, Iām disagreeing with you or Steve Major about the increased resource usage. Two things to keep in mind - the version of JRE has changed along with Java so comparing it to previous version doesnāt help. Youāre saying āmy old car didnāt do thatā. Iāve been using Openfire for about 5 years now and have also seen the steady increase of resource usage but Iāve also seen significant improvements to Openfire along with it.
Chasing CPU utilization so far has gotten you nowhere, what is the system load when you Openfire becomes unusable? What OS? How many cores? How much Ram? Average Load? JRE version?
We run on a Poweredge 2650, two dual core processors, 12GB Ram (thatās memory), CentOS 6.4, JRE 1.7, Openfire 3.10.0.
Again, CPU utilization and system load are two different things. Do you have any plugins running? Have you tried removing them and adding them back one at time to see where the issue is coming from.
When we moved to 3.10.0 the Asterisk-IM plugin caused openfire to not let anyone log-in using their chat client.
Thereās definitely a problem; in fact I think thereās a number of problems with different impact.
I do need debug logs and thread dumps to trace the issues, though.
FWIW, I believe one is an Apache Mina bug relating to IPv6; Iām more worried about the Openfire internal ones (I suspect thereās two).
Knowing if youāre running a chatroom service would be interesting.
Sorry, there is a typo in my previous response. Iām not disagreeing there is a problem. Iām asking that they report back with usable information and not complaints about 100% utilization, which is mostly meaningless in regard to system performance.
Respectfully, you may wish to re-read this thread youāve already claimed to have read. These are multiple reports of once the symptom of high CPU utilization goes on for awhile, the server becomes unresponsive.
I expect my new car to have additional features and maybe consume more resources, and sure my old car didnāt do some things the new one does, but it certainly didnāt peg the tachometer then stall the car in the middle of the highway.
I posted my specs in a different thread until this one took off and it is referenced in the bug report. I noted a completely clean install of OpenFire & Iām using the same Java (8) I have been using with the older install. The difference is the version of OF.
It sounds like youāre not having any problems, thatās fantastic - for you.
What is the system load when CPU utilization is at 100%?
With respect, CPU utilization and system load are two different things. The fact that Iām not having any issue with a very similar stack would suggest that it is related to the system you are running Openfire on more than it is Openfire. It looks like the majority of the issues are for those running on Ubuntu 14, or OSX. In which case I would ask has anyone tried older versions of their JRE?
Have you done a test VM build with a different OS than the one youāre having issue with? Can you repost or provide a link to your system specs so we can see whatās going on?
Dave, I run a chatroom service with one chatroom on our server. See my post above for other details about my setup.
I guess the real question is, is anyone running 3.10.0 and not experiencing this issue? What is your configuration?
1 Like
Iām running into these issues on CentOS 5.11.
Quad Core
12GB RAM
CentOS 6.4 Server 32bit
MySQL 5.5
PHP 5.3
Apache 2.2
Openfire 3.10.0 stable installed via RPM
JRE 1.7.0_76
Only issue is with Asterisk-IM plugin, which is old.
Java memory usage is 95.96MB of 910.25MB available.
How long has it been running without the Asterisk-im plugin?
After upgrading to 3.10.0 we were not able to log-in using Spark 2.7 or any other desktop client. It didnāt matter what OS, or client we used. (Win XP/7, OSX 10.9, Ubuntu 12/14 - Trillian, Pidgin, Jitsi, Spark). It was process of elimination to determine that it was that plugin causing the issue. Weāve been running without it for 10 days now. I posted here at the time. Asterisk-IM Plugin causes users not to be able to login after upgrade to 3.10