Created attachment 815 [details]
After updating to C153 Testing from C152 Stable, Suricata uses 2 to 3 times the CPU percentage it did previously. Changes show up on the CPU and the Load graphs and consistently put Suricata at the top of the htop list. Systems with plenty of CPU resources are okay but slower systems may overload.
This is known upstream, but no solution is available, yet.
As a temporary 'workaround(?) I pushed a 'downdate' to 'suricata 5.0.5' today.
This version is running here without any changes in cpu load. Runs like 5.0.4.
Don't know if we'll like that.
I also updated 'libhtp' (used by 'suricata') to 0.5.36.
I have posted on the upstream bugtracker.
I believe that we might have to pull the release and rebuild it all again with a downgraded suricata.
A fix has been posted upstream:
Working on it. ('Devel' is running...)
Created attachment 858 [details]
Load graph for 5.0.5 (idle)
Tested with 5.0.5 - compared to a patched 6.0.1 - see attachments (idle load).
IMHO there is NO significant improvements. The cpu load is almost as high as before.
Running on Core 153 /x86_64.
Created attachment 859 [details]
Load graph for patched 6.0.1 (idle)
I posted your findings upstream on the same ticket and requested for it to be reopened since this fix does not actually fix the problem.
I have no idea how we can help the suricata team apart from testing and validating any proposed fixes.
Just looked around a bit.
Searching for 'usleep()' found a lot of pages, declaring this function as "obsolete, use nanosleep() instead". Always assuming that usleep is the culprit in this case.
But I have no idea how to change that.
It looks like our glibc is using nanosleep internally when calling usleep():
Created attachment 860 [details]
6.0.1 patched with usleep(5000)
(It looks like changing the usleep value to 200 already gives a big improvement, but setting it much higher to something like 5000 gives better results.), I'm now testing with "usleep (5000);".
First impressions: CPU load is significantly lower (0.6-~2%) compared to the previous build, raising to ~35% during a 100MBit download (1GB).
But: "Need to look at what the impact is of changing this."
I cannot judge what the consequences might be, too...
There is some movement to track this:
This ticket/change is targeted for suricata 7, which seems to suggest that we are going to skip the 6 series.