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
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:
tocluster_flow
- set
runmode:
toworkers
- activate and configure the
cpu-affinity
settings
In the end what really did the trick I think, was settingmmap-locked:
andtpacket-v3:
toyes
. But in order to use themmap-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