OPNsense-bot
commented
2 years ago This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Is your feature request related to a problem? Please describe.
I'm frequently finding my Protectli FW4B maxing out the CPU even though I don't run that much traffic through my firewall. After some research I've identified some non-routing, non-filtering tasks as being at fault. These are tasks that are important for monitoring, though (node_exporter, flowd_aggregate.py), and I'd prefer to not do away with them altogether. However, they're not time-critical, and if there were some means to restrict how many of the 4 available cores could be reserved to service those tasks even if they took a little longer to complete, I'd be fine with them taking a bit longer to complete as long as the rest of the cores were dedicated 100% to more time-critical tasks (such as traffic filtering, routing, SNAT/DNAT, etc.).
This CPU load issue sometimes seems to result in false detection of "downed" circuits b/c the pings from dpinger can't be processed in the correct time, so it leads to unnecessary circuit failovers b/c of "dirty" reads.
Describe the solution you like
I'd like to be able to specify a (set of) CPU core(s) to which non-time-critical background tasks should be restricted such that there's less of a chance of them overrunning the box's processing capabilities and causing errant behavior as a side-effect.
This could also include GUI rendering/servicing, etc. The intention is to be able to impose hard(ish) limits on how much of the available processing power certain not-time-critical background tasks can consume so as to avoid possible interference with more time-critical tasks.
Perhaps this is as simple as employing better "nice" priorization?
Describe alternatives you considered
I lack enough knowledge of BSD or the OPNSense O/S component to make an intelligent determination in this regard.