Suricata tuning contradictions - help

[rosswakelin]

Hi everyone.
We are just standing up a new sensor node, and trying to tune the NIC/CPU settings in Suricata to get the best performance. The device has a single AMD CPU, 16 cores/32 threads, 3Ghz, with Intel 10Gb NICs.
We are seeing zero packet loss in Zeek, but Suricata tends to sit at about 8-10% packet loss, with peaks of up to 40% when things like backups cross the network (we are not worried about the backup peaks). Overall CPU usage sits around 5%, and memory usage around 45%. The 5 minute load average is 2.1. The current traffic being seen is less that 500MB/s when this sensor could see up to 10Gb/s. We have pinned Suricata to threads 2-30 (even cores only) and Zeek to threads 3-31 (odd cores only).
I have been reading the various papers on the net about tuning Suricata, and how people managed to get up to 40Gb throughput with zero packet loss etc. but some of the recommendations are contradictory. The one that stands out at the moment is receive queues on the NIC. Our NICs support 32 receive and 32 transmit queues, and some of the recommendations say we should bind individual queues to individual interrupts to individual cores, to ensure we are using all the available cores. Other recommendations say that we should tune the NIC to one receive queue, so that packets are not processed out of order causing false results. The number of recommendations seems to be split 50/50 each way.
Anyone out there got any gems of wisdom?
Thanks, Ross

[TOoSmOotH]

First thing to look at would be how many rules you are running. Go through and disable categories that are not of use. I would bpf out the backups.

Also check this out. It's old but some of it is still useful. https://suricon.net/wp-content/uploads/2016/11/SuriCon2016_MichalPurzynski_PeterManev.pdf