Bug #15262
openCaptive Portal Has High CPU Interrupts With Large Number of Users
0%
Description
When 700+ Captive Portal users are in use, CPU interrupts will cause high load averages to occur. This can lead to connectivity problems, such as packet loss on WAN uplinks, webConfigurator responsiveness issues, etc.
Tested with a customer who had load averages of 14-16 with Captive Portal on with 1400+ users. Once Captive Portal was turned off, load averages dropped to 0.5.
Load seems higher for Captive Portal when there is significant numbers of users since the transition to pf from ipfw.
Updated by Kris Phillips over 1 year ago
Customer in ticket 2947838007 is reportedly running into this issue as well.
Updated by Kris Phillips about 1 year ago
- Status changed from New to Confirmed
Marking this as confirmed, as we have multiple instances of people reporting issues with high CPU usage with a high number of captive portal users.
Updated by Muhammad Waseem Ul Haq about 1 year ago
Kris Phillips wrote in #note-4: [[
Marking this as confirmed, as we have multiple instances of people reporting issues with high CPU usage with a high number of captive portal users.
I reported this issue in the forums in February 2024. We have large deployments with 8,000 to 10,000 captive portal users. Version 2.6 continues to function perfectly with the captive portal; however, attempts to switch to 2.7.2 have twice resulted in the same issue: excessively high CPU load, with CPU core 0 consistently reaching 100% utilization while other cores remain available. This appears to be related to the switch from IPFW to PF.
Updated by Boris Dietrich 12 days ago
I would like to confirm that we have the same issue. Our two Netgate 8300 are used exclusively for Captive Portal and suffer from high CPU load at 1000-1500 users. Additionally, at some point (after weeks), Daemons will fail, nginx will display 50x, ssh will stop accepting connections leading to a manual reboot. Of course, I can't tell if these two issues are related. I've tried to implement a cronjob /etc/rc.restart_webgui daily, but it doesnt prevent the daemons from failing at some point and CPU load is still high. Running on 25.11.1.
Updated by Boris Dietrich 12 days ago
There's already an open ticket at TAC, 40730123594, with status outputs shared twice. Last activity today.
Also, its impossible to share /status.php when the daemons crash, as the firewall is unreachable at that time.