76% of how much? That is not necessarily bad or “too much”.
What happens after a day or two or three? Does it crash or does it keep
running in the 70% level?
Server eventually becomes unresponsive with the CPU railing at 99%
Thanks to the help of FusionReactor and a whole lot of testing I finally determined the root of the cause of my issues (thanks in part to this post sending me down the cfhttp path - https://lucee.daemonite.io/t/upgrade-to-lucee-5-2-3-35-results-in-gc-overhead-limit-crashes/2766).
Essentially I had two components (Twitter and a Emergency Broadcast System) that were retrieving json files via cfhttp. These connections were never closing and every new session opened another connection, which grew the heap and eventually resulted in the server becoming unresponsive.
These components hadn’t changed and I ran into the issue when I upgraded to
Lucee 5.2. So not necessarily an issue with Lucee, but something changed in
how cfhttp connections are handled between 5.1 and 5.2.
T.
Hi there. Just thought I’d add to this discussion… No real new data other than to say that, like everyone else here, my experience migrating up from Lucee 5.0.0.252 to 5.2.5.20 on Linux CentOS 7 was really horrible. Things initially looked stable after the install, but after about 6 hours, memory problems emerged and then the servers stopped entirely. Luckily, I only ever update 2 of our 4 web servers in the cluster, so I could fail these boxes out of production in our load balancer quickly and avoid downtime.
We’ve been on 5.0.0.252 since 2016, amazingly stable. After moving to 5.2.5.20, two different web servers crashed within hours. Sure, we might have messy cfhttp sessions (as suggested above), but shouldn’t those be handled similarly between 5.0 and 5.2? Or at least noted and warned? In my view, 5.2 is NOT production ready. This is a major, major issue.
Anyone running 5.2.6 seeing any issues with cfthread? We are still running 5.2.5.20 and want to make sure it is rock solid before we update Lucee.
Thanks in advance!
We are migrating our e-commerce platform to Lucee 5.2 too.
I tested 5.2.6.60 and latest snapshot (5.2.7.56) on windows server 2008R2 (just used the vivio installer with JRE8).
Both versions crashed within the hour where same code on Railo 4.2 (currently used in production) is stable for ages and is even faster on Railo 4.2 (how is that possible after 2-3 years of lucee development, i hoped lucee 5 will give me performance boost instead)
I hope the Lucee team is eager enough to fix this problem asap, it’s very important for many great lucee users out there. This problem is open for several months (at least) now. I think it’s time to tackle this thing.
If you guys tell me what you need exactly (logs, heapdump from FR?) then i will make sure you get it soon.
the first step to solving any problem is understanding what the problem is
it’s your code base, so have you identified which specific bits (i.e. requests, tec) of your
code run slower under 5? What do you mean by slower, 5% 50%