Suricata using only one core

Started by ejprice, March 03, 2017, 04:55:36 AM

Previous topic - Next topic
Forgive my newbieness but it appears to me that Suricata while being multithreaded is only using one core on my OPNSense box. I noticed this while doing multiple downloads of large files simultaneously.

I initially noticed it because I wanted to check the load on my new OPNSense firewall. After running 'top' from the shell I noticed one CPU running Suricata was pinned at 100% while the other was relatively idle. I then did some checking about Suricata to see if it was multithreaded or multiprocess. It claims to be multithreaded. I tried the downloads again, same behavior so I put 'top' into threads mode. Sure enough, multiple threads but the ones under load were running on the same core.

I don't believe this is the correct or expected behavior for a multithreaded application.

System in question is OPNSense 17.1.2 running on a x86_64 Core 2 Duo with 2GB ram and SSD drive.

Steps to reproduce:

1) Download multiple streams of "stuff" at a sufficiently high download speed

2) run top or something else to watch the load on the system. Press "H" to view all the threads under load running on one core (there were other Suricata threads but with little to no CPU time)

Can anyone else confirm this behavior?
"Computers allow people to make mistakes faster than anything else in history, with the possible exception of handguns and tequila."

Same for me.
Suricata is running on one interface for me (em1) and shows the following threads when it's under high load:

PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
33051 root       103    0   898M   475M CPU1    1   3:49 100.00% suricata{W#01-em1+}
33051 root       -92    0   898M   475M select  2   0:42  16.55% suricata{W#01-em1}
33051 root        20    0   898M   475M uwait   2   0:24   0.33% suricata{FM#01}
33051 root        20    0   898M   475M nanslp  1   0:18   0.16% suricata{suricata}


Anyone else try testing this? It seems to be a very limiting factor on a SMP box.
"Computers allow people to make mistakes faster than anything else in history, with the possible exception of handguns and tequila."

Me too on a APU2C4 with latest 17.1.3

Me too on a J1900 Router Qotom-Q190G4N  17.1.3

Same here on 3 different test installs of opnsense for 17.1.3.  Only using 1 core.

Any chance to force suricata using more cores?

I've tried changing some of the Suricata settings but so far no luck.
"Computers allow people to make mistakes faster than anything else in history, with the possible exception of handguns and tequila."

March 29, 2017, 05:09:30 PM #8 Last Edit: March 29, 2017, 05:28:39 PM by tcmax
Here ist a part from the boot logfile.
Maybe that´s the reason...?!

"Starting suricata.
29/3/2017 -- 16:57:19 - <Warning> - [ERRCODE: SC_WARN_FASTER_CAPTURE_AVAILABLE(275)] - faster capture option is available: NETMAP (--netmap=igb1). Use --pcap=igb1 to suppress this warning
29/3/2017 -- 16:57:19 - <Info> - Including configuration file installed_rules.yaml.
Starting CRON...done."

Hmm. My command line shows I'm using netmap. I think that is the out-of-the-box setting.

/usr/local/bin/suricata -D --netmap --pidfile /var/run/suricata.pid {...}
"Computers allow people to make mistakes faster than anything else in history, with the possible exception of handguns and tequila."

I seem to get Suricata to distribute load more evenly among cores by switching the runmode from "workers" to "autofp".

The work that Suricata assign cores is quite different with the runmodes, described shortly here:
http://suricata.readthedocs.io/en/latest/configuration/suricata-yaml.html#ips-mode

What I did was change

runmode: workers

to

runmode: autofp

in /usr/local/etc/suricata/suricata.yaml and restart suricata using the gui.

when i change this parameter, my throughpout drops from 7.6 mb/sec to 5.4 mb/sec :-(
HW: APU2C4