In order to have cu affinity, created this config:
- management-cpu-set:
cpu: [ "1-5","32-37" ] # include only these CPUs in affinity settings
- receive-cpu-set:
cpu: [ "0-5","32-37" ] # include only these CPUs in affinity settings
Now is see core 32 almost all of the time at 100% cpu, the other cores from the receive/management range dance between 0 and 10% . Sometimes core 32 decreases and load seems to spread to the other cores in the range, but that is just for a few seconds and 32 hits 100% again.
Looking at an overload problem?
Red Hat Enterprise Linux release 8.8 (Ootpa)
4.18.0-477.15.1.el8_8.x86_64 #1 SMP Fri Jun 2 08:27:19 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux
This is Suricata version 7.0.1-dev (becb8cefc 2023-08-11)
btw receive-cpu-set is only used in Autofp mode, so not relevant for workers runmode - it is possible to comment it out.
Considering you probably have many workers enabled, have you considered increasing number of managers and recyclers - by default only 1 is enabled and that might explain why 1 core is hitting 100% CPU usage.
TBH having 100% CPU on management cores seems weird to me anyway - no matter how big your flow table is and how many workers you have.
But I would try to increase the manager/recycler count and see if that would help
I’ve tested the config and also noticed high usage of the functions that you mentioned. Then I tried to replace 2MB with 1GB hugepages. And both this problem and the UNIX socket problem went away.
I think we can take that as a solution though I’ll try to understand a bit more why 2MB hugepages are causing the issues…
You can try it out with e.g. sudo dpdk-hugepages.py --pagesize 1G --setup 8G
But note that hugepages require continuous memory so it is less likely to obtain 1GB hugepages than 2MB when memory gets fragmented as the OS runs.
I guess Peter meant the CPU model name that you have installed on your machine. So he was looking for info from e.g. lscpu like Intel® Xeon® Processor E5-4617