Increased Memory and CPU Spikes (causing latency/outage) with 2.4.5
-
Any news on this?
The whole thing is a serious desaster and no minor problem in my opinion. -
I think that we did not get any news with this issue until the final 2.5.0 version (which will be released not earlier than in a year or maybe - two).
-
@Woodsomeister said in Increased Memory and CPU Spikes (causing latency/outage) with 2.4.5:
Any news on this?
The whole thing is a serious desaster and no minor problem in my opinion.Unfortunately the current "solution" is to stay with the 2.4.4 version until we see a stable version.
-
@Woodsomeister I agree. It's not a minor problem. Looks like at least all major virtual environments have this problem. Even physical machines with a larger network and/or ip-table setup.
-
It's not being ignored.
2-4-5-high-latency-and-packet-loss-not-in-a-vm
If I were a betting man I would bet it's a regression in pf in 11.3Stable. I don't see that getting priority from the FreeBSD project. 12.x is the priority. Hope I am wrong.
-
I can verify this is happening on my Hardware based system (XG-1541 in CARP setup purchased from Netgate)
I upgrade my standby to 2.4.5 and immediately saw the CPU spiking and bad ping results, so I did not update my primary. EDIT: as soon as I submitted this I had packet loss and 3-4 second pings from the standby, so I'm happy I didn't update the primary.
After updaing the pfBlocker-ng package the ping/cpu on the standby router has returned to normal, but I'm a bit wary to proceed with upgrading the primary.
Looking at the redmine case and referenced freebsd errata, I'm not sure if the errata is being reference as a cause or solution?
If it is a potential solution will an updated pfctl be made available?
Many thanks
EDIT: Also I noticed the cpu spikes/packet timeouts were causing the secondary firewall to promote itself so I had to disable CARP on it until this is sorted.
-
@ScottCall said in Increased Memory and CPU Spikes (causing latency/outage) with 2.4.5:
EDIT: Also I noticed the cpu spikes/packet timeouts were causing the secondary firewall to promote itself so I had to disable CARP on it until this is sorted.
In my 2 cases I have simply had to turn off the backup firewall and switch off HA settings because it's just unusable.
-
Netgate XG-1537 HA pair
-
Netgate C-2758 HA pair
-
-
I too have been having the same issues and as other users described it tends to be initiated by loading a web page.
I was getting 502: Bad Gateway when trying to visit the CP. I did a restore recent config; no change. Then I restarted php-fpm from console and it seems OK for now. But it's been coming/going since the upgrade to 2.4.5...!
I should note my setup is pretty simple; just a home setup with no HA or big lists of anything.
-
Ive finally managed to downgrade to 2.4.4
-
So I read the entire thread. Problem as far as I understand is the new pfctl.patch in 2.4.5. I am trying to go back to 2.4.4. The problem is I do not have a backup of 2.4.4. Can I create a back up of 2.4.5 and restore those configs to 2.4.4?
Also where can I find the 2.4.4 version of pfsense and do I just do a fresh boot from it and restore using the 2.4.5 backup? -
@Infective said in Increased Memory and CPU Spikes (causing latency/outage) with 2.4.5:
Also where can I find the 2.4.4 version of pfsense
A search of the messages on this forum would have given you the answer to your question, but if you open a ticket with Netgate support, they will give you a link to the 2.4.4_p3 image so you can downgrade.
-
Is there any updates Netgate can, or have shared, re possible solutions for the increased latency issues with 2.4.5? I'm evaluating options re stick with it vs roll-back.
-
@q54e3w said in Increased Memory and CPU Spikes (causing latency/outage) with 2.4.5:
Is there any updates Netgate can, or have shared, re possible solutions for the increased latency issues with 2.4.5? I'm evaluating options re stick with it vs roll-back.
I don't think Netgate have said anything official. Your best solutions to try are the following:
- Greatly reduce the amount of entries in your Firewall table (by removing blacklists/blocklists etc)
- If virtualised, change to 1 vCPU. This seems to have fixed it for almost all Hyper-V users I've seen
- Rollback to 2.4.4p3
-
Thanks, I didn't think I'd missed anything but wanted to check. I'm not actually expecting any definitive updates, but an indication of confidence would be useful for me.
I'm running on metal and have stripped back as far as I can go re rules and anything that invokes updates, but even so, with a fairly busy albeit bursty firewall I see increased latency to around the 150-250ms level which starts to affect video call quality etc. -
https://forum.netgate.com/post/908806