Suricata high capture.kernel_drops count

What is the diff with and without mmap-locked percentage wise?
I think you might find that thread helpful - https://redmine.openinfosecfoundation.org/issues/2918 it seems related.

Without mmap-locked it is: ~0.49%
With mmap-locked it is: ~0.02%

I already read this thread earlier… that is how I found out about the default Limit for the memory lock of 64kb. But thanks for pointing out again because I did not saw the comment in there about the systemd service as I first read it.^^
I had to add LimitMEMLOCK=infinity to the suricata.service file. Now I can start suricata as service with mmap-locked enabled. I will monitor suricata and the drops over the weekend and the next Monday and report back on Thuesday.

In case everything is fine, I would like to summarize what we have done here and mark it as solution, unless some of you want to do that :smiley:

Sorry for the late response.
Anyways, I am glad to report that everything is working fine. The dropped packages are way below 1% (0.1% when I last checked).
Thanks for the great help!

At first, I want to thank everybody who helped me with this problem!

If anybody should have a similar problem, here what we did:

  • set cluster-type: to cluster_flow
  • set runmode: to workers
  • activate and configure the cpu-affinity settings
    In the end what really did the trick I think, was setting mmap-locked: and tpacket-v3: to yes. But in order to use the mmap-locked option you have to edit the /etc/security/limits.conf file and add something like this to the End of the file, otherwise suricata will fail because it can’t lock enough memory:

suricata hard memlock unlimited
suricata soft memlock unlimited

Additional if you start suricata as Service you have to add LimitMEMLOCK=infinity to the suricata.service file.
You can read more about it here: Bug #2918: Unable to mmap, error Resource temporarily unavailable - err seems OS specific - Suricata - Open Information Security Foundation

1 Like